|
Tuesday 24 August 2010 1:27:00 am
Mmm, many different things on this post:
- being able to prevent editors from adding/removing blocks: would be nice, add a feat. request. You could maybe obtain that result via a custom workflow event
- being able to prevent editors from switching layouts: just define in zone.ini that your frontpage class has only one layout available for it. Being able to specify it by node can be done by using one different fp class per node, which is doable albeit a chore if you have too many fp objects
- being able to specify which blocks can be added to which zones: would be nice, add a feat. request
And then the last one: being able to use ezflow block code in a simplified "object/attribute" way. Before ezflow was released, having 'blocks' which linked to content was a common requirement, and it was often implemented with schemas such as the following:
- frontpage obj has one (or more) obj-relations attribute that links to block objects
- block objects live in a separate content section
- block objects are linked to the content they display via aon obj relation attribute (manual block), or have custom templates that do whatever they need (auto/custom block). This means having a couple of different "block" classes with different template override rules
- this can be augmented with grouping block objects into "column" containers. Then many fp objects can link to the same 'column'. If the column is displayed on the side of the web page (ie. outside actual content area), the node tpl for fp passes its related column id to the pagelayout tpl via the persistent variable, and the pagelayout tpl is in charge of fetching the column and displaying it. If the column for a node is undefined, the column of its parent is used etc...
This is all fine and dandy. What you miss is the ajax-based 'add node to block' interface, possibly some fine-grained policy on what obj classes to be able to add to obj-relation attributes, timeline preview and of course the "queueing" of content. Back on topic: if you want to use the templates of custom blocks (that do everything in the template) in your own code, it's going to be pretty easy. Create an obj with an attribute to store eg. the rss feed url or twitter id, and include the desired block template passing those values to it. Good luck trying to extract a single existing 'zone' or 'block' to put it in an external datatype though - I fear that besides rewriting code that reads stuff from ezm_block and ezm_pool, you will break the existing logic - most of which is coded in ezflowoperations.php, and is brittle and convoluted at times...
Principal Consultant International Business
Member of the Community Project Board
|
