down with override.ini

Next topic

Author	Message
Gaetano Giunta	Tuesday 20 April 2010 9:05:53 am A crazy idea: why not get rid completely of override.ini? - it is not flexible enough: given the fact that the order of its blocks is important, you cannot have many extensions adding to it piecewise. This means extensions cannot easily ship with new content classes and templates that apply to them - separating override templates from standard ones makes little sense anyway. The net result is just doubling the number of directories where to search templates - it is hard to debug and prone to errors - many of the things achieved with using override templates can be achieved using an {if} statement within the template anyway (mostly true for 'site/specific' templates, as opposed to 'extension/generic' templates) A different proposal Put override templates in the same root dir as main templates, using different names and/or subfolders; Define override rules which are akin to css selectors: for a node selectors could be the node id, section and class (no more than 3 for sanity) For override templates, the filename is used to specify the selectors The chosen template would be the one that matches most selectors totaling the most weight. This means the tpl engine would look for the following files to display a node: /node/view/full/classidentifier#sectionid#node.tpl /node/view/full/#sectionid#node.tpl /node/view/full/classidentifier##node.tpl /node/view/full/##node.tpl ... /node/view/full/classidentifier##.tpl /node/view/full.tpl Comments are welcome... Principal Consultant International Business Member of the Community Project Board
Kristof Coomans	Wednesday 21 April 2010 8:02:14 am I'm afraid your proposal will come with too many limitations. The current override conditions are pretty powerful, this is something you will not be able to reflect entirely in a template naming scheme. I agree though that it would be a good thing to not have 2 directory structures anymore to search for templates (no longer one for standard templates + one for overrides), as this is confusing anyway. I guess this might break a lot of websites though, as they might have equally named overriding templates that are used only in certain conditions. Bad practice... but understandable because the template override system has a long (partially undocumented) history. independent eZ Publish developer and service provider \| http://blog.coomanskristof.be \| http://ezpedia.org
Gaetano Giunta	Wednesday 21 April 2010 2:20:45 pm I do agree that the new scheme looses a lot of power, but if 90% of the existing cases can be covered easily, and 10% with ugly if/include-based-templates, I think it would be worth anyway. Besides reducing the number of directories by removing the unnecessary 'override', the filenames for override templates would suddenly become standard. No more looking around for pagelayout_popup vs. popup_pagelayout (unless of course users go rampant with include). Principal Consultant International Business Member of the Community Project Board
Kristof Coomans	Wednesday 21 April 2010 11:10:57 pm Additionally, you can not use the same template for multiple conditions, unless you start symlinking it (which gets messy as well IMHO). independent eZ Publish developer and service provider \| http://blog.coomanskristof.be \| http://ezpedia.org