Re: [Zope-dev] Re: [Plone-developers] zcml entry points
Martijn Faassen wrote at 2007-10-24 18:38 +0200: ... I disagree with the position that should not ever treat an adapter registration as an implementation detail to provide some default behavior. Sometimes the behavior of a library *relies* on certain adapters being registered. An example is an adapter registration to generate an appropriate error message (if no more specific adapters are registered by the user of the library). But requiring that a more specific adapter must be registered can be a bit tedious -- as it may require to define an additional (and unnatural) interface that derives from the original one -- just to be able to register a more specific adapter... -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Plone-developers] zcml entry points
On 10/25/07, Chris McDonough [EMAIL PROTECTED] wrote: I can definitely see a use in the zope3 and grok world for some more ZODB persistent configuration. Maybe much of what is today actually done in ZCML shuld rather be done there? Does it need to be persistent or just placeful? I'd want it to be persistent, but I can't say it needs to be. :-) Something GenericSetup-like to configure which components should be configured would be nice. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Plone-developers] zcml entry points
Hello, On 10/24/07, Chris McDonough [EMAIL PROTECTED] wrote: [snip] I think maybe more abstractly, it might be useful to think about separating based on libraries vs. applications. Libraries should be as policy-free as possible (otherwise they're not libraries, they're applications). Applications, however, must declare policies (or they would be useless, this is what makes them applications [sorry for the reflexive tautology]), but this makes them not useful outside of some context. If a library egg contains an entry point that either loaded or returned a stream for the moral equivalent of meta.zcml, that would be fine. But it would be less OK for an egg which represented a library's ZCML to contain adapter and utlity registrations. However, if the egg represented an application, it would be fine for it to do either. I am not sure I see such a hard distinction between applications and libraries myself, at least not on the boundary of adapter and utility registrations. I think in many cases libraries provide default implementations of adapters, for instance, and default global utility registrations. This makes the library more easy to use without having to do extra work, if at least the defaults apply to your work. You may of course have to override the default behavior, by registering an adapter for a more specific interface or class, or by registering a local utility. Take a library that registers views (multi adapters) as widgets for form fields, for instance. Do you consider this to be an application-like library? I consider this to be a library. Zope 2 'Products' are usually applications in a sense, because they are *never* useful outside the context of Zope-the-application- server, and that's why Five's automagical load of meta, configure, and overrides ZCML is completely appropriate for them, and why it would make sense, if products became eggs, to have all of their ZCML loaded at Zope startup time. I can see where you're coming from, but you are stretching the terminology to its breaking point, though. I really don't consider XMLWidgets or ParsedXML to be *applications*. I don't even consider Formulator to be one. We have to look at their intent. Their intent is to provide components that can be reused to create applications. If anything, that mean they're libraries (that provide components). They're libraries highly coupled to Zope 2, of course. Zope 2 isn't designed with loosely coupled libraries in mind. It's not great. But to go calling these 'applications' I think might cause a lot of confusion in terminology. I'd like us to come up with better words to describe heavily-coupled versus loosely-coupled, and policy-heavy versus policy-light or policy-free. [snip] We don't really complain too badly right now that setuptools doesn't infer all of our dependencies for us from import statements in the packages it contains in order to prevent us from having to manually specify dependencies in our setup.py. We might not, but this one has been in the back of my mind for a while. I'd like to be able to write code where I just import something, and poof, it's there. Of course such automation can be dangerous, but hopefully it could be tamed. With Zope we add a third structure to it: ZCML dependencies, and while two places may be an accident, three places definitely calls for some thinking about don't repeat yourself. Again, I see your points. I think it makes sense for libraries to be light on policy. It's also clear that for instance ZMI views are too much policy one gets with a typical Zope 3 library. I don't think we should however consider all libraries that register a few adapters as 'policy heavy'. Once we take the ZMI registrations out, is what is left policy-heavy or policy-light? Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Plone-developers] zcml entry points
On 10/24/07, Tres Seaver [EMAIL PROTECTED] wrote: Maybe we need to add a term, 'plugin', to describe things like Zope2 products which register only behavior and not addable applications. The line gets fuzzy here, too: PAS uses 'plugin' to describe an object which is added to a persistent user folder, and then configured to perform one or more roles in its framework. Oooh, there's another term, 'framework'. In my mind, 'frameworks' declare interfaces for 'plugins' to supply. OTOH, 'frameworks' don't want every possible plugin to be magicdally configured: they are all about explicit configuration. It gets fuzzy, but I think trying to get a common usage of the words is useful. And your usage seems useful. Note that of course PAS is both a plugin *and* a framework in this usage. :-) Plone makes configuring QuickInstaller-enabled products explicit: the site manager gets to choose at runtime (not at startup), and can change her mind later. In that sense, Plone is 'framework'-like, rather than 'application'-like. I can definitely see a use in the zope3 and grok world for some more ZODB persistent configuration. Maybe much of what is today actually done in ZCML shuld rather be done there? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Plone-developers] zcml entry points
On Oct 24, 2007, at 12:54 PM, Lennart Regebro wrote: On 10/24/07, Tres Seaver [EMAIL PROTECTED] wrote: Maybe we need to add a term, 'plugin', to describe things like Zope2 products which register only behavior and not addable applications. The line gets fuzzy here, too: PAS uses 'plugin' to describe an object which is added to a persistent user folder, and then configured to perform one or more roles in its framework. Oooh, there's another term, 'framework'. In my mind, 'frameworks' declare interfaces for 'plugins' to supply. OTOH, 'frameworks' don't want every possible plugin to be magicdally configured: they are all about explicit configuration. It gets fuzzy, but I think trying to get a common usage of the words is useful. And your usage seems useful. Note that of course PAS is both a plugin *and* a framework in this usage. :-) Plone makes configuring QuickInstaller-enabled products explicit: the site manager gets to choose at runtime (not at startup), and can change her mind later. In that sense, Plone is 'framework'-like, rather than 'application'-like. I can definitely see a use in the zope3 and grok world for some more ZODB persistent configuration. Maybe much of what is today actually done in ZCML shuld rather be done there? Does it need to be persistent or just placeful? Being able to specify multiple component registries via ZCML (maybe within a container tag), and then associating one with a 'site' has always seemed to make sense to me. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: [Plone-developers] zcml entry points
On Oct 22, 2007, at 11:46 AM, Lennart Regebro wrote: On 10/22/07, Martijn Faassen [EMAIL PROTECTED] wrote: In at least 3 places we express dependency information. For different *purposes* in each case, but we still state something like: 1. we use dependency X, and please download and install it 2. we use dependency X, please configure it 3. we use dependency X, please import the following from it It'd be nice if I only had to say I want to import from dependency X, please make sure it's there and available. Actually this is a little bit like zc.resourcelibrary can make resources appear on your page headers when you write code that needs it. Of course this is sometimes not possible, as there's not enough information available, or there are multiple separate ways to configure it. In the end I guess this all is just more arguments for separating the functions and the views into separate eggs. I think maybe more abstractly, it might be useful to think about separating based on libraries vs. applications. Libraries should be as policy-free as possible (otherwise they're not libraries, they're applications). Applications, however, must declare policies (or they would be useless, this is what makes them applications [sorry for the reflexive tautology]), but this makes them not useful outside of some context. If a library egg contains an entry point that either loaded or returned a stream for the moral equivalent of meta.zcml, that would be fine. But it would be less OK for an egg which represented a library's ZCML to contain adapter and utlity registrations. However, if the egg represented an application, it would be fine for it to do either. Zope 2 'Products' are usually applications in a sense, because they are *never* useful outside the context of Zope-the-application- server, and that's why Five's automagical load of meta, configure, and overrides ZCML is completely appropriate for them, and why it would make sense, if products became eggs, to have all of their ZCML loaded at Zope startup time. However, the presence of some ZCML in a non-Product library doesn't mean that its ZCML should be loaded, IMO. Zope-3-the-application uses site.zcml to selectively load configurations, and I think that's about the right policy. We could devise some way of spelling the equivalent of site.zcml as an entry point for eggs-that-are-applications, and as any include package directives in that zcml should just work, there probably shouldn't be any additional machinery within zcml itself to cause other ZCML to be loaded from multiple packages via some omnibus search pattern. We don't really complain too badly right now that setuptools doesn't infer all of our dependencies for us from import statements in the packages it contains in order to prevent us from having to manually specify dependencies in our setup.py. This is because even though it probably could (py2exe does something like this), it's more trouble than it's worth in because the import statements themselves don't contain enough information (version, location, is it an absolute requirement or a nice-to-have?) if you want to treat the dependencies as independently release-managed entities. That said, if you just want to freeze some configuration up, it would become reasonable to treat some sandbox as a fully-configured set of things that should get packaged up as a glob and shipped off, but this is the opposite of what we want to do with eggs in the long term, I think. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
