Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
Malthe Borch mbo...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
On Sat, Dec 4, 2010 at 9:21 PM, Ross Patterson m...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
On Sat, Dec 04, 2010 at 12:21:02PM -0800, Ross Patterson wrote: Malthe Borch mbo...@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 signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
On 02/12/2010 08:15, Malthe Borch wrote: I always found configuration overrides (e.g. ZCML'sincludeOverrides 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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
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 signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
On 3 December 2010 11:41, Chris Withers ch...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
On Thu, Dec 2, 2010 at 3:15 AM, Malthe Borch mbo...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
On 2 December 2010 13:34, Benji York be...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
On 2 December 2010 14:37, Stephan Richter srich...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
Am 02.12.2010, 14:19 Uhr, schrieb Malthe Borch mbo...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Context priority as an alternative to configuration directive overrides
-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 mbo...@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 tsea...@palladion.com Palladion Software Excellence by Designhttp://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- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
