Position of overrides in override.ini.append should not affect the application of the overrides

Author Message

Alex Jones

Wednesday 17 September 2003 6:34:54 am

Okay, that was a long title. I'm not sure how to put it more succinctly. Sorry.

Anyway, I propose that the order of overrides in the override.ini.append files should not be taken into account when presenting a page to the user. It is an unnecessary, and often confusing state of affairs.

Right now, if I happen to place a class override at line 10 of my override.ini.append and a node override (which is of class 10) on line 15, the class override will be used instead of the override that applies to the specific node. That really doesn't make sense. This additional dimension doesn't provide any real benefit that I can see. Please correct me if I am missing something.

While I am aware that we can place the overrides to avoid this situation, we shouldn't have to. We as developers should be able to structure the document as we wish.

Ultimately, I feel that the specificity of the override itself should take precedence. So, a node override would be used instead of a class override. Section overrides would also be used over a class override, though not over a node override.

Overrides should follow the example of Cascading Style Sheets as they are much the same in principle. The only reason I could see this not working would be due to additional processing of the override.ini.append file to check the specificity of the override, but surely that could be worked out in the long run.

Alex

Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]

<i>When in doubt, clear the cache.</i>

Alex Jones

Monday 05 January 2004 11:35:38 am

Anyone else have any thoughts on this topic?

Alex

Alex
[ bald_technologist on the IRC channel (irc.freenode.net): #eZpublish ]

<i>When in doubt, clear the cache.</i>

Paul Borgermans

Monday 05 January 2004 12:18:56 pm

Hi Alex,

I think this will lead to a debate on what should have precedence over something else. On the other hand, what you propose sounds reasonable:

node > section > class

But personally, I don't care much now (3.3) that we can specify the order (precedence) in the admin interface

regards

-paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Marco Zinn

Monday 05 January 2004 5:07:08 pm

I agree to both of you ;)
With 3.3, priority of override in the override.ini can be changed via web. I couldn't test this yet, so i don't know, if the priority will just move the blocks in the .ini OR of the blocks get a new "priority" attribute, which determined the order.
While this will be enough for me, an "intelligent" approach would keep the priority problem away from the user (admin).
Yes, and this will lead to the discussion of "what is more important than some other thing?".

Marco
http://www.hyperroad-design.com

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.