Context priority as an alternative to configuration directive overrides
I always found configuration overrides (e.g. ZCML's <includeOverrides> directive) to be difficult to manage and hard to get right. How about an alternative where you can put a priority on a configuration context like so: <adapter zcml:priority="100" ... /> Default priority would be 0, traditional overrides get the maximum priority. ZTK components might then all be at the default priority, making it trivial to add a preferred component in a custom setup. If accompagnied by a sane amount of logging output, this system might facilitate plugging in components "for the rest of us". \malthe
On Thu, Dec 2, 2010 at 3:15 AM, Malthe Borch <mborch@gmail.com> wrote:
I always found configuration overrides (e.g. ZCML's <includeOverrides> directive) to be difficult to manage and hard to get right.
How about an alternative where you can put a priority on a configuration context like so:
<adapter zcml:priority="100" ... />
I appreciate the flexibility inherent in that approach, but personally, I'd be frightened of such a system. I sometimes have problems figuring out which directives are active in the current system, if I had to reason about dozens of priority levels I think it'd be worse.
If accompagnied by a sane amount of logging output, this system might facilitate plugging in components "for the rest of us".
I don't quite follow the "for the rest of us" part. Will you expand on that? -- Benji York
On 2 December 2010 13:34, Benji York <benji@benjiyork.com> wrote:
I appreciate the flexibility inherent in that approach, but personally, I'd be frightened of such a system. I sometimes have problems figuring out which directives are active in the current system, if I had to reason about dozens of priority levels I think it'd be worse.
I think there would in general be either no priority set or a single, non-trivial priority. It's true that priorities in general open up for some complexity (e.g. ordering ``zope.viewlet`` viewlets), but if used sparingly, I think it's a reasonable approach.
I don't quite follow the "for the rest of us" part. Will you expand on that?
As far as I understand, for a ZCML include override to work properly, you need to carefully make sure that your includes are in the exact right order and on the same level. In a system where two packages are trying to override the same component (should arguably never be the csae, but it is frequently), it can be difficult to get it right. Priorities on the other hand are absolute, globally. It's easy for anyone to see that the highest priority wins, no matter the order of inclusion. \malthe
On Thursday, December 02, 2010, Malthe Borch wrote:
As far as I understand, for a ZCML include override to work properly, you need to carefully make sure that your includes are in the exact right order and on the same level. In a system where two packages are trying to override the same component (should arguably never be the csae, but it is frequently), it can be difficult to get it right.
This explanation helped me to understand where you come from. I think I would be okay with the priority feature, but could we maybe limit it to the <configure> element? Since you can use this element anywhere and it can be nested, it should work well. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
On 2 December 2010 14:37, Stephan Richter <srichter@cosmos.phy.tufts.edu> wrote:
This explanation helped me to understand where you come from. I think I would be okay with the priority feature, but could we maybe limit it to the <configure> element? Since you can use this element anywhere and it can be nested, it should work well.
That's reasonable. The priority needs to get applied to the configuration context anyway and this might (I don't recall the exact implementation) correspond to the <configure> element anyway. I'll try to get an implementation working. \malthe
Am 02.12.2010, 14:19 Uhr, schrieb Malthe Borch <mborch@gmail.com>:
As far as I understand, for a ZCML include override to work properly, you need to carefully make sure that your includes are in the exact right order and on the same level. In a system where two packages are trying to override the same component (should arguably never be the csae, but it is frequently), it can be difficult to get it right.
Priorities on the other hand are absolute, globally. It's easy for anyone to see that the highest priority wins, no matter the order of inclusion.
-1 on priorities - how do you resolve the case where the priorities are the same? The proposed solution introduces an additional complexity which could get even more baffling than the current one. I would much prefer a cascading/layered/subclass approach but I suspect this might not be possible with the current implementation, so I sympathise entirely with your complaint. As a developer you kind of imagine that your application layer ought to "win" just as your subclass "wins". Can we get some kind of diamond rule? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/02/2010 03:43 PM, Charlie Clark wrote:
Am 02.12.2010, 14:19 Uhr, schrieb Malthe Borch <mborch@gmail.com>:
As far as I understand, for a ZCML include override to work properly, you need to carefully make sure that your includes are in the exact right order and on the same level. In a system where two packages are trying to override the same component (should arguably never be the csae, but it is frequently), it can be difficult to get it right.
Priorities on the other hand are absolute, globally. It's easy for anyone to see that the highest priority wins, no matter the order of inclusion.
-1 on priorities - how do you resolve the case where the priorities are the same? The proposed solution introduces an additional complexity which could get even more baffling than the current one.
I would much prefer a cascading/layered/subclass approach but I suspect this might not be possible with the current implementation, so I sympathise entirely with your complaint. As a developer you kind of imagine that your application layer ought to "win" just as your subclass "wins". Can we get some kind of diamond rule?
I'm -100 on priorities as well. I'm not quite sure I understand the issue: the person who should "win" is the one configuring the outermost layer (the site, rather than any soi-disant "reusable policy" shipped with a library). No ZCML shipped as part of a library should *ever* contain an <includeOverrides> element, period. One library writer arrogating the right to override another library writer's ZCML is insane. We need to give up on the idea that we can solve the "reusable policy" problem with more machinery: the correct first-order solution is to create local copies and fix them up by hand (the second-order solution is to quit shipping so much "mandatory" ZCML in our packages). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz4HCUACgkQ+gerLs4ltQ5kGACgrWlvc9XBldb8B//wBn2FMcQC MIEAoMbraokLM4Dz8wqxumaGJ3kvdypR =yP08 -----END PGP SIGNATURE-----
On 02/12/2010 08:15, Malthe Borch wrote:
I always found configuration overrides (e.g. ZCML's<includeOverrides> directive) to be difficult to manage and hard to get right.
How about an alternative where you can put a priority on a configuration context like so:
<adapter zcml:priority="100" ... />
I'm -sys.maxint on priorities.
Default priority would be 0, traditional overrides get the maximum priority. ZTK components might then all be at the default priority, making it trivial to add a preferred component in a custom setup.
I'd much prefer it to just be an "order of execution" thing, the nyou have total and flexible control. Combined with some logging about why something is as it is and you have your solution. The current includeOverrides stuff is a bit of a hack... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On 3 December 2010 11:41, Chris Withers <chris@simplistix.co.uk> wrote:
I'd much prefer it to just be an "order of execution" thing, the nyou have total and flexible control. Combined with some logging about why something is as it is and you have your solution.
It's not always possible to control the order of execution. For instance, with z3c.autoinclude, the order of inclusion is somewhat random and although you can to some extend control the order via explicit dependency includes, it's hard to work around 3rd party packages that provide own overrides. The problem with e.g. request layers as a means to prioritize is that views adapt on (context, request) which makes it unfit for the purpose if you have any views that specialize on the context interface. Instead, priorities on the configuration level would be an easy solution if you are trying to simply get a component to kick in. \malthe
On 03/12/2010 10:51, Malthe Borch wrote:
On 3 December 2010 11:41, Chris Withers<chris@simplistix.co.uk> wrote:
I'd much prefer it to just be an "order of execution" thing, the nyou have total and flexible control. Combined with some logging about why something is as it is and you have your solution.
It's not always possible to control the order of execution.
It's *always* possible, zcml is essentially one big declarative file...
For instance, with z3c.autoinclude, the order of inclusion is somewhat random and although you can to some extend control the order via explicit dependency includes, it's hard to work around 3rd party packages that provide own overrides.
...anything else is just a kludge or a hack. The Plone world is full of these, of course, but I'd prefer not to polute zcml with that. Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Am 03.12.2010, 11:51 Uhr, schrieb Malthe Borch <mborch@gmail.com>:
It's not always possible to control the order of execution. For instance, with z3c.autoinclude, the order of inclusion is somewhat random and although you can to some extend control the order via explicit dependency includes, it's hard to work around 3rd party packages that provide own overrides.
Sounds like a bug in autoinclude to me.
The problem with e.g. request layers as a means to prioritize is that views adapt on (context, request) which makes it unfit for the purpose if you have any views that specialize on the context interface.
I don't understand this sentence. Are you talking about layers as in the Zope 3 skin layer? Otherwise I've nothing but good experiences with views using interface subclassing for specialisation.
Instead, priorities on the configuration level would be an easy solution if you are trying to simply get a component to kick in.
As Marius has already noted, this sounds very much like adding more complexity to solve the apparent existing complexity: swallowing the spider to catch the fly. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
On Thu, Dec 02, 2010 at 09:15:44AM +0100, Malthe Borch wrote:
I always found configuration overrides (e.g. ZCML's <includeOverrides> directive) to be difficult to manage and hard to get right.
How about an alternative where you can put a priority on a configuration context like so:
<adapter zcml:priority="100" ... />
-1 Adding more complexity is not a solution for "the configuration mechanism is too complex to get right". Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
Malthe Borch <mborch@gmail.com> writes:
I always found configuration overrides (e.g. ZCML's <includeOverrides> directive) to be difficult to manage and hard to get right.
How about an alternative where you can put a priority on a configuration context like so:
<adapter zcml:priority="100" ... />
Default priority would be 0, traditional overrides get the maximum priority. ZTK components might then all be at the default priority, making it trivial to add a preferred component in a custom setup.
If accompagnied by a sane amount of logging output, this system might facilitate plugging in components "for the rest of us".
I'd like to echo Malthe's concern here. I've had many issues with this as well. Recently I had a conversation with someone or read something about using add-on specific stacked component registries. Would this be the best way to solve these kind of problems? Unfortunately I can't remember where I head/read of this. Ross
On Sat, Dec 4, 2010 at 9:21 PM, Ross Patterson <me@rpatterson.net> wrote:
Recently I had a conversation with someone or read something about using add-on specific stacked component registries. Would this be the best way to solve these kind of problems? Unfortunately I can't remember where I head/read of this.
That sounds even worse ;) I yet have to see a convincing example of where the current approach fails. The "application" can always use overrides as a last resort to integrate various libraries. No library should ever use overrides, as this prevents the application endpoint from doing so. If we have cases where libraries use overrides, then we need to fix those - not add two layers of complexity more on top of the machinery. Hanno
On Sat, Dec 04, 2010 at 12:21:02PM -0800, Ross Patterson wrote:
Malthe Borch <mborch@gmail.com> writes:
I always found configuration overrides (e.g. ZCML's <includeOverrides> directive) to be difficult to manage and hard to get right.
I'd like to echo Malthe's concern here. I've had many issues with this as well.
Recently I had a conversation with someone or read something about using add-on specific stacked component registries. Would this be the best way to solve these kind of problems? Unfortunately I can't remember where I head/read of this.
Sounds like z3c.baseregistry. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
participants (9)
-
Benji York -
Charlie Clark -
Chris Withers -
Hanno Schlichting -
Malthe Borch -
Marius Gedminas -
Ross Patterson -
Stephan Richter -
Tres Seaver