Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
Hi there, It is my understanding that the ZTK is primarily to adopt proven solutions that arise from our community that we intend to be shared by this community. I'll also note that Martian is already in use in combination with Bluebream, Zope 2 and Grok. With that, I was thinking, concerning alternative configuration mechanisms I think we should have: * a clear statement of use cases concerning configuration. * a weighing of the importance of these use cases, underlying reasons, etc. * an evaluation whether Martian or Venusian can fulfill those use cases. * if use cases are found that Martian or Venusian cannot fulfill, then an evaluation whether these can be made to fulfill them by modifying them. Regards, Martijn ___ 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 )
[Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
I haven't read through the whole discussion in detail, so I'm sure I repeat some of what has been said already, but here is my point of view. 1. Yes, Grok is pretty implicit. If it's soo implecit is a matter of taste, but much of the implicitness makes sense. You typically do have a model and a view and a template, and the model and view are typically in one module, and has a name similar to the template. That implicitness however only makes sense in the specific context of web applications. There is no reasonably way to have that implicitness with components and adapters. So a configuration for the ZCA in general can't be implicit. 2. That doesn't mean we can't use grok-style configuration though. 3. Although Python 3 means we can't. We'll have to use decorators. 4. zope.interface already does, and zope.component will as well, once it's ported. That means we get things like: class IMyFace(Interface): whatevah class IMyFeet(Interface): something @implementer(IMyFace) class MyFace(object): yeahyeah @adapter(IMyFace, IMyFeet) class FootInMouth(object): def __init__(self, mouth, foot): pass The @adapter decorator so far only handles functions, but will be extended to classes once we port zope.component. I think also adapter today will only mark the object as adapts(...) does, but you will still use zcml to register the adapter. So probably we still need @adapter (as it already exists) and also another decorator (say @adapt() maybe?) that will both mark the class and register it in the registry, and hence do the same as the adapter ... / directive does today. Then we have subscriber, utility, resource and view directives. There's no particular reason I know of that means they couldn't be class decorators as well. That takes care of most of the configuration needed for the ZCA itself. How to deal with the rest probably gets more obvious once we've done this. //Lennart ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
Also, the decorators will always return the original component, meaning they can easily be used as post-config: @adapter(IMyFace, IMyFeet) class FootInMouth(object): ... Will mark the class as an adapter, but not register it. @adapt(IMyFace, IMyFeet) class FootInMouth(object): ... Will mark and register. @adapter(IMyFace, IMyFeet) class FootInMouht(object): ... adapt(FootInMouth)() Will register a previously marked adapter, and adapt(FootInMouth)(IMyFace, IMyFeet) Will mark and register. This means you can, if you want, still have the interfaces in one file, the implementations in one file, and the registrations separately (say, configure.py), thereby getting the same separation as you had with interfaces.py, components.py and configure.zcml. Your package just needs to *not* import the configure.py file. On Mon, Mar 21, 2011 at 12:47, Lennart Regebro rege...@gmail.com wrote: I haven't read through the whole discussion in detail, so I'm sure I repeat some of what has been said already, but here is my point of view. 1. Yes, Grok is pretty implicit. If it's soo implecit is a matter of taste, but much of the implicitness makes sense. You typically do have a model and a view and a template, and the model and view are typically in one module, and has a name similar to the template. That implicitness however only makes sense in the specific context of web applications. There is no reasonably way to have that implicitness with components and adapters. So a configuration for the ZCA in general can't be implicit. 2. That doesn't mean we can't use grok-style configuration though. 3. Although Python 3 means we can't. We'll have to use decorators. 4. zope.interface already does, and zope.component will as well, once it's ported. That means we get things like: class IMyFace(Interface): whatevah class IMyFeet(Interface): something @implementer(IMyFace) class MyFace(object): yeahyeah @adapter(IMyFace, IMyFeet) class FootInMouth(object): def __init__(self, mouth, foot): pass The @adapter decorator so far only handles functions, but will be extended to classes once we port zope.component. I think also adapter today will only mark the object as adapts(...) does, but you will still use zcml to register the adapter. So probably we still need @adapter (as it already exists) and also another decorator (say @adapt() maybe?) that will both mark the class and register it in the registry, and hence do the same as the adapter ... / directive does today. Then we have subscriber, utility, resource and view directives. There's no particular reason I know of that means they couldn't be class decorators as well. That takes care of most of the configuration needed for the ZCA itself. How to deal with the rest probably gets more obvious once we've done this. //Lennart ___ 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 ) ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, Mar 21, 2011 at 7:47 AM, Lennart Regebro rege...@gmail.com wrote: ... 4. zope.interface already does, and zope.component will as well, once it's ported. That means we get things like: class IMyFace(Interface): whatevah class IMyFeet(Interface): something @implementer(IMyFace) class MyFace(object): yeahyeah @adapter(IMyFace, IMyFeet) class FootInMouth(object): def __init__(self, mouth, foot): pass The @adapter decorator so far only handles functions, but will be extended to classes once we port zope.component. I think also adapter today will only mark the object as adapts(...) does, but you will still use zcml to register the adapter. So probably we still need @adapter (as it already exists) and also another decorator (say @adapt() maybe?) that will both mark the class and register it in the registry, and hence do the same as the adapter ... / directive does today. Then we have subscriber, utility, resource and view directives. There's no particular reason I know of that means they couldn't be class decorators as well. That takes care of most of the configuration needed for the ZCA itself. How to deal with the rest probably gets more obvious once we've done this. I'm not going to comment any more on the broader thread unless/until I have something specific to propose. Having said that, I'd like to go on record as wanting to review the zca port to Python 3 before it's finalized. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
Hi there, For Martian, Python 3 support is mostly an issue of making class directives work as class decorators. I'm not sure what Lennart means by point 1. Anyway, Grok's configuration is dependent on the rules you give it, so it's possible to have a completely explicit set of directives with no implicit fallback to default values whatsoever. Martian supports that scenario right now. The only implicit behavior left would be the grokking process, which generally recognizes subclasses of particular base classes as something to register. You could do away with this using class decorators as well, but that would require some changes to Martian to allow it to recognize things that way. (and it won't work for grokking instances, just classes and functions) Note that Pyramid as far as I understand also has a non-ZCML configuration method that is closer to ZCML. Regards, Martijn ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, Mar 21, 2011 at 14:17, Martijn Faassen faas...@startifact.com wrote: Anyway, Grok's configuration is dependent on the rules you give it, so it's possible to have a completely explicit set of directives with no implicit fallback to default values whatsoever. Martian supports that scenario right now. Sure, but I'm of course referring to how it behaves by default, including the associations made by the grokking process. I think that makes sense in a webapp, but not otherwise, and we should at least as a start concentrate on the generic component architecture case. For Martian, Python 3 support is mostly an issue of making class directives work as class decorators. And the same goes for zope.component support, of course. With martian, the registration is then done by the grokking process, but I think decorators would be a process that is more acceptable to the Python world in general. Instances does indeed require something else than decorators, I hadn't thought of that, that's a drawback. //Lennart ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, Mar 21, 2011 at 10:07 AM, Lennart Regebro rege...@gmail.com wrote: On Mon, Mar 21, 2011 at 14:17, Martijn Faassen faas...@startifact.com wrote: ... With martian, the registration is then done by the grokking process, but I think decorators would be a process that is more acceptable to the Python world in general. Instances does indeed require something else than decorators, I hadn't thought of that, that's a drawback. I think Martijn raised a good question about the conceptual interaction of class decorators and inheritance. (Arguablly the questions applies to the advice-based syntax as well.) If I see: @some_decorator class Base: class Sub(Base): ... I'm going to wonder how the decorator affects Sub. (Wondering is work. :) This might be OK for @implements and maybe @adapts, which describe behavior, but start feeling wonky to me for something like: @utility. Maybe it's enough to document what the directives do. Or maybe something less attached to the class definition would make sense. I don't know what the right answer is ... at least not yet. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On 03/21/2011 03:07 PM, Lennart Regebro wrote: On Mon, Mar 21, 2011 at 14:17, Martijn Faassenfaas...@startifact.com wrote: Anyway, Grok's configuration is dependent on the rules you give it, so it's possible to have a completely explicit set of directives with no implicit fallback to default values whatsoever. Martian supports that scenario right now. Sure, but I'm of course referring to how it behaves by default, including the associations made by the grokking process. I think that makes sense in a webapp, but not otherwise, and we should at least as a start concentrate on the generic component architecture case. For Martian, Python 3 support is mostly an issue of making class directives work as class decorators. And the same goes for zope.component support, of course. We have a much more extensive directive abstraction though. That should make it harder and easier at the same time. :) With martian, the registration is then done by the grokking process, but I think decorators would be a process that is more acceptable to the Python world in general. Instances does indeed require something else than decorators, I hadn't thought of that, that's a drawback. Do we really care about the Python world in general? Is that relevant to the discussion? Can't we just talk about what we care about? The Python world in general uses metaclasses for this kind of stuff, which relies on base classes too, by the way. You'll still need a module importing process, as I sketched out elsewhere, if you use class decorators, to have the class decorators kick in at all for modules you don't need to import otherwise. Note that we do support function decorators with Martian. Regards, Martijn ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On 03/21/2011 03:28 PM, Jim Fulton wrote: I don't know what the right answer is ... at least not yet. :) In Django and sqlalchemy declarative a meta class is used for this kind of configuration. Since that is subclassing, it implies inheritance, I think. Of course metaclasses are not very good for this as they're surprising in other ways and use unstructured configuration happening at import time. Regards, Martijn ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, Mar 21, 2011 at 15:28, Jim Fulton j...@zope.com wrote: This might be OK for @implements and maybe @adapts, which describe behavior, but start feeling wonky to me for something like: @utility. Well, the wonkyness comes from @utility *not* being inherited, while @implements would be. That could be confusing. It wold be possible to let @utility be inherited if it's done by scanning, though. But under what name in that case? I think that possibly would be even *more* confusing. It may be that decorators isn't the right answer for registration. In that case scanning is an option, unless we simply go for straight imperative configuration. @implementer(IMyFace) @adapter(IMyFoot) class FootInFace(object): def __init__(self, foot, face) self.foot = foot self.face = face component.utility(FootInFace()) It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. On Mon, Mar 21, 2011 at 15:36, Martijn Faassen faas...@startifact.com wrote: Do we really care about the Python world in general? Is that relevant to the discussion? Can't we just talk about what we care about? The Python world in general uses metaclasses for this kind of stuff, which relies on base classes too, by the way. Yeah, but that's to a large extent because class decorators still are relatively new. You can't use them if you need to support Python 2.5. You'll still need a module importing process, as I sketched out elsewhere if you use class decorators, to have the class decorators kick in at all for modules you don't need to import otherwise. Is that a problem? In the end, no matter what you do, the module needs to be imported. :-) That a utility doesn't get registered unless you import a specific module somewhere in the app doesn't seem like a problem to me. //Lennart ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, Mar 21, 2011 at 10:38 AM, Martijn Faassen faas...@startifact.com wrote: On 03/21/2011 03:28 PM, Jim Fulton wrote: I don't know what the right answer is ... at least not yet. :) In Django and sqlalchemy declarative a meta class is used for this kind of configuration. Since that is subclassing, it implies inheritance, I think. Ick. Of course metaclasses are not very good for this as they're surprising in other ways Agreed. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On 03/21/2011 04:08 PM, Jim Fulton wrote: On Mon, Mar 21, 2011 at 10:38 AM, Martijn Faassen faas...@startifact.com wrote: On 03/21/2011 03:28 PM, Jim Fulton wrote: I don't know what the right answer is ... at least not yet. :) In Django and sqlalchemy declarative a meta class is used for this kind of configuration. Since that is subclassing, it implies inheritance, I think. Ick. Of course metaclasses are not very good for this as they're surprising in other ways Agreed. Martian allows you to use a similar spelling to metaclasses (base classes), without the weird surprises during run-time (after configuration is already done), and without significant import-time side-effects. With megrok.rdb I actually use SQLAlchemy declarative without their declarative metaclass, as the SQLAlchemy folks were kind enough to tweak their config code so I could call it directly from a grokker. Regards, Martijn ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote: On Mon, Mar 21, 2011 at 15:28, Jim Fulton j...@zope.com wrote: This might be OK for @implements and maybe @adapts, which describe behavior, but start feeling wonky to me for something like: @utility. Well, the wonkyness comes from @utility *not* being inherited, while @implements would be. That could be confusing. It wold be possible to let @utility be inherited if it's done by scanning, though. But under what name in that case? I think that possibly would be even *more* confusing. It may be that decorators isn't the right answer for registration. In that case scanning is an option, unless we simply go for straight imperative configuration. @implementer(IMyFace) @adapter(IMyFoot) class FootInFace(object): def __init__(self, foot, face) self.foot = foot self.face = face component.utility(FootInFace()) It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. It's important to me, at least. Registration-on-import effectively requires that there only be a single component registry for all applications in a process. This is often fine for a given deployment, but as a framework strategy it seems very limiting. - C ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On 03/21/2011 10:59 AM, Chris McDonough wrote: On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote: It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. It's important to me, at least. Registration-on-import effectively requires that there only be a single component registry for all applications in a process. This is often fine for a given deployment, but as a framework strategy it seems very limiting. +1. Pyramid has proven (IMHO) that a component registry can be friendly to developers without being global. Shane ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, Mar 21, 2011 at 12:59 PM, Chris McDonough chr...@plope.com wrote: On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote: ... It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. It's important to me, at least. Registration-on-import effectively requires that there only be a single component registry for all applications in a process. This is often fine for a given deployment, but as a framework strategy it seems very limiting. I'll note that this thread started with me saying: ZTK projects use ZCML too much. Ideally, ZCML should only have to be used when we want to override something. and: I think we ought to come up with a much cleaner way of defining default configuration. The intent of this thread, for me, was to come up with a cleaner way to define *default* configurations. The scope is narrower than all configuration. I'm thinking of use cases like the ones Tres mentioned where you now use default arguments to queryUtility and queryAdapter. Having a static way to express default configuration in no way prevents you from utilizing local registries, any more than hard coding defaults in calls to component-lookup APIs does. So where do static definitions make sense? I think static definitons make sense in library code when you own one of the interfaces, as in Tres' examples. I'm not positive, but I strongly suspect that this situation covers lots of registrations we now do in ZCML. I would argue that static definitions make sense in application code when you're pretty sure how you want to hook things up, although in this case, whether to express these application defaults in Python or ZCML (or whatever) is a matter of taste. (There are also some potential conflict issues that might make doing this sort of configuration statically unattractive.) One could argue about how much can be expressed as a static default configuration. Maybe elimination of all ZCML is too ambitious a goal, but I think we can avoid a lot of ZCML we have now. I'll probably make some concrete proposal at a later time. I trying to avoid saying more in this thread now, but I thought it was important try to be clearer aout what this thread was supposed to be about. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
On Mon, 2011-03-21 at 14:13 -0400, Jim Fulton wrote: On Mon, Mar 21, 2011 at 12:59 PM, Chris McDonough chr...@plope.com wrote: On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote: ... It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. It's important to me, at least. Registration-on-import effectively requires that there only be a single component registry for all applications in a process. This is often fine for a given deployment, but as a framework strategy it seems very limiting. I'll note that this thread started with me saying: ZTK projects use ZCML too much. Ideally, ZCML should only have to be used when we want to override something. and: I think we ought to come up with a much cleaner way of defining default configuration. The intent of this thread, for me, was to come up with a cleaner way to define *default* configurations. The scope is narrower than all configuration. I'm thinking of use cases like the ones Tres mentioned where you now use default arguments to queryUtility and queryAdapter. Having a static way to express default configuration in no way prevents you from utilizing local registries, any more than hard coding defaults in calls to component-lookup APIs does. So where do static definitions make sense? I think static definitons make sense in library code when you own one of the interfaces, as in Tres' examples. I'm not positive, but I strongly suspect that this situation covers lots of registrations we now do in ZCML. I would argue that static definitions make sense in application code when you're pretty sure how you want to hook things up, although in this case, whether to express these application defaults in Python or ZCML (or whatever) is a matter of taste. (There are also some potential conflict issues that might make doing this sort of configuration statically unattractive.) One could argue about how much can be expressed as a static default configuration. Maybe elimination of all ZCML is too ambitious a goal, but I think we can avoid a lot of ZCML we have now. I'll probably make some concrete proposal at a later time. I trying to avoid saying more in this thread now, but I thought it was important try to be clearer aout what this thread was supposed to be about. I personally don't see the benefit of externalizing default configuration over having defaults be part of the call-site code as per Tres' example. Having the defaults in the code itself makes it much, much easier for people reading the code to understand the garden path. - C ___ 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] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/21/2011 02:13 PM, Jim Fulton wrote: On Mon, Mar 21, 2011 at 12:59 PM, Chris McDonough chr...@plope.com wrote: On Mon, 2011-03-21 at 15:53 +0100, Lennart Regebro wrote: ... It's easy and clear, but has the drawback of encouraging that registration is done on import time, while scanning separates the registration from the definition. I'm not sure how important that is. It's important to me, at least. Registration-on-import effectively requires that there only be a single component registry for all applications in a process. This is often fine for a given deployment, but as a framework strategy it seems very limiting. I'll note that this thread started with me saying: ZTK projects use ZCML too much. Ideally, ZCML should only have to be used when we want to override something. and: I think we ought to come up with a much cleaner way of defining default configuration. The intent of this thread, for me, was to come up with a cleaner way to define *default* configurations. The scope is narrower than all configuration. I'm thinking of use cases like the ones Tres mentioned where you now use default arguments to queryUtility and queryAdapter. Having a static way to express default configuration in no way prevents you from utilizing local registries, any more than hard coding defaults in calls to component-lookup APIs does. So where do static definitions make sense? I think static definitons make sense in library code when you own one of the interfaces, as in Tres' examples. I'm not positive, but I strongly suspect that this situation covers lots of registrations we now do in ZCML. I would argue that static definitions make sense in application code when you're pretty sure how you want to hook things up, although in this case, whether to express these application defaults in Python or ZCML (or whatever) is a matter of taste. (There are also some potential conflict issues that might make doing this sort of configuration statically unattractive.) One could argue about how much can be expressed as a static default configuration. Maybe elimination of all ZCML is too ambitious a goal, but I think we can avoid a lot of ZCML we have now. I'll probably make some concrete proposal at a later time. I trying to avoid saying more in this thread now, but I thought it was important try to be clearer aout what this thread was supposed to be about. FWIW, I just added 'queryAdapterFactory' and 'queryMultiAdapterFactory' APIs to zope.component on a branch: http://svn.zope.org/zope.component/branches/tseaver-queryAdapterFactory/ These APIs make the almost never overridden / dependency injection case as compact for adapters as for utilities. 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/ iEYEARECAAYFAk2HqCYACgkQ+gerLs4ltQ7PFQCgnyoPFi8u8joVkA6wwDEL1ff0 IAcAn1l0s48CLGzVDRsF8tW32If7HCRm =WoQO -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 )
Re: [Zope-dev] Re: zcml filtering
Previously Philipp von Weitershausen wrote: Marius Gedminas wrote: On Tue, Aug 05, 2008 at 10:36:30PM +0100, Martin Aspeli wrote: Subscribers and subscription adapters are particularly bad in this way, since they are unnamed and thus can't be overridden, only amended to. We've talked about an off switch for ZCML before. Given that we have a configuration machine that's capable of doing overrides based on discriminators, why couldn't we have support for negatives, e.g. unconfigure utility ... / /unconfigure This could use a special _context that would record callables and discriminators, and then look for the corresponding callables/discriminators in the real context and remove them before that context was configured. Subscribers don't have discriminators, unfortunately. Indeed they don't. That just makes them harder to track down, though. I'm working on a package for this functionality in z3c.unconfigure right now. Name inspired by Martin's suggestion above; my original prototype used had a different name but this is much better :). I am using z3c.unconfigure now and it works perfectly. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 )
[Zope-dev] Re: zcml filtering
Marius Gedminas wrote: On Tue, Aug 05, 2008 at 10:36:30PM +0100, Martin Aspeli wrote: Subscribers and subscription adapters are particularly bad in this way, since they are unnamed and thus can't be overridden, only amended to. We've talked about an off switch for ZCML before. Given that we have a configuration machine that's capable of doing overrides based on discriminators, why couldn't we have support for negatives, e.g. unconfigure utility ... / /unconfigure This could use a special _context that would record callables and discriminators, and then look for the corresponding callables/discriminators in the real context and remove them before that context was configured. Subscribers don't have discriminators, unfortunately. Indeed they don't. That just makes them harder to track down, though. I'm working on a package for this functionality in z3c.unconfigure right now. Name inspired by Martin's suggestion above; my original prototype used had a different name but this is much better :). ___ 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: zcml filtering
On Wednesday 06 August 2008, Philipp von Weitershausen wrote: I'm working on a package for this functionality in z3c.unconfigure right now. Name inspired by Martin's suggestion above; my original prototype used had a different name but this is much better :). Couldn't we just merge zc.configuration and z3c.unconfigure into zope.configuration? Everyone who wants to use our configuration system certainly wants this functionality as well. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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: zcml filtering
El 6 Aug 2008, a las 16:47 , Stephan Richter escribió: On Wednesday 06 August 2008, Philipp von Weitershausen wrote: I'm working on a package for this functionality in z3c.unconfigure right now. Name inspired by Martin's suggestion above; my original prototype used had a different name but this is much better :). Couldn't we just merge zc.configuration and z3c.unconfigure into zope.configuration? Everyone who wants to use our configuration system certainly wants this functionality as well. I'm +1 on zc.configuration. z3c.unconfigure, however, will contain zope.component specific code to unconfigure subscribers (which currently have no useful discriminator). So it's a hack to make it work with existing Zope code out there. If zope.component.zcml were changed to emit useful actions for subscriber / (and interface /, too!), we could solely rely on shooting down actions and the code could find its way into zope.configuration. That will only help us with future Zope code, not with existing code out there (which this is for). Feel free to undertake this :) ___ 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 )
AW: [Zope-dev] Re: zcml filtering
Hi Philipp Betreff: Re: [Zope-dev] Re: zcml filtering [...] I'm +1 on zc.configuration. z3c.unconfigure, however, will contain zope.component specific code to unconfigure subscribers (which currently have no useful discriminator). So it's a hack to make it work with existing Zope code out there. If zope.component.zcml were changed to emit useful actions for subscriber / (and interface /, too!), we could solely rely on shooting down actions and the code could find its way into zope.configuration. That will only help us with future Zope code, not with existing code out there (which this is for). Feel free to undertake this :) That's a good argument but valid for any development or improvment on existing code/packages. The bad thing is that we now have 3 packages for one thing doing right. I'm +1 too for a simple zope.configuration package which offers the API for doing configuration how it should. What do you think about to release z3c.unconfigure and merge it to zope.configuration after the release. So we have both options and a simple setup for the future. Regards Roger Ineichen ___ 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: zcml filtering
El 6 Aug 2008, a las 17:17 , Roger Ineichen escribió: I'm +1 on zc.configuration. z3c.unconfigure, however, will contain zope.component specific code to unconfigure subscribers (which currently have no useful discriminator). So it's a hack to make it work with existing Zope code out there. If zope.component.zcml were changed to emit useful actions for subscriber / (and interface /, too!), we could solely rely on shooting down actions and the code could find its way into zope.configuration. That will only help us with future Zope code, not with existing code out there (which this is for). Feel free to undertake this :) That's a good argument but valid for any development or improvment on existing code/packages. It's about being pragmatic. We need to this to work on existing code (Zope 3.3 to be exact). We can't just upgrade zope.configuration. The bad thing is that we now have 3 packages for one thing doing right. It's unfortunate, but things could be worse. I'm +1 too for a simple zope.configuration package which offers the API for doing configuration how it should. What do you think about to release z3c.unconfigure and merge it to zope.configuration after the release. So we have both options and a simple setup for the future. Not forgetting to give subscriber / and interface / decent discriminators. But yes, that sounds like a great idea. Feel free to do it ;). I probably won't have time to worry about this any time soon. I'm just trying to fix an issue at hand. ___ 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 )
[Zope-dev] Re: zcml filtering
Philipp von Weitershausen wrote: But yes, that sounds like a great idea. Feel free to do it ;). I probably won't have time to worry about this any time soon. I'm just trying to fix an issue at hand. Thanks a lot for doing that, by the way. :) Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
[Zope-dev] Re: zcml filtering
Wichert Akkerman wrote: I have an interesting problem in the world of Zope 2 and zcml: CMFCore registers an handleDynamicTypeCopiedEvent subscriber which does something that I want to prevent at all costs, so I am trying to make sure it is not subscriber. That appears to be impossible! I can not unsubscribe it, since the subscriber directive dynamically creates a subscriber factory and registers that, so I have nothing to call unregisterSubscriptionAdapter with. I can not use zc.configuration to prevent the CMFCore zcml from being loaded since I have no control over if its zcml is loaded before mine, and if CMFCore gets to go first the zc.configuration exlusion trick no longer works. This trick also has a downside: you can only exclude whole files, which in this case would mean I would have to re-register half a dozen subscribers by hand and pray that a future CMFCore would not add another one and I'ld miss that. Normally if all else fails you can resort to a monkey patch. Even that does not work here since the original method is wrapped in an adapter factory and then registered with the site manager, and at that point using a monkey patch to replace the original method is no longer useful. I have to admit that I'm baffled. Subscribers and subscription adapters are particularly bad in this way, since they are unnamed and thus can't be overridden, only amended to. We've talked about an off switch for ZCML before. Given that we have a configuration machine that's capable of doing overrides based on discriminators, why couldn't we have support for negatives, e.g. unconfigure utility ... / /unconfigure This could use a special _context that would record callables and discriminators, and then look for the corresponding callables/discriminators in the real context and remove them before that context was configured. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
[Zope-dev] Re: zcml entry points
Hey, On 10/20/07, Tres Seaver [EMAIL PROTECTED] wrote: Martijn Faassen wrote: [snip] Since this appears to be a rare case that is the exception, what about using the new ZCML exclude framework for this case? You need to know what you are doing, but this use case is for people who know exactly what they're doing anyway, right? It isn't that rare: how many people want to turn off the Rotterdam skin in Z3, for instance? In general, the authors of a library package can't anticipate how their code will be used; the ZCML they provide is intended to cover the cases they know or imagine most people want. ZCML represents policy, not mechanism, and hence is inherently less reusable than code. I'd be nice if alternate policies could be expressed in the dependency structure itself then. This might imply that commonly-used policy ZCML should be in its own package altogether. With automatic loading, you'd get this as soon as you install the package. If the policy is very particular to a particular application and has no reuse potential at all, it has no business being in our repository anyway (except as part of this application, of course). 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: zcml entry points
Hey, On 10/20/07, Dieter Maurer [EMAIL PROTECTED] wrote: [snip] Zope 2 had (for products) all three things together. It was felt that this was a too tight coupling. Therefore, for Zope 3 the paradigma explicit is better than implicit (a paradigma, that I personally dislike and find wrong) was used. Now, you want again more things to happen implicitly. In my view, this is natural -- but not in the Zope 3 spirit... Sure, but while I fully acknowledge problems with the Zope 2 approach, in my view we've gone a bit overboard at times with the Zope 3 spirit. :) There is value in thinking about compact expression. The great benefit with Zope 3 is that we frequently actually *know* the aspects of what we want to express compactly, as we tend to be expressing these aspects separately. I hope we can foster a spirit where after we have factored out the independent aspects we can look at them again and make their expression more compact, at least for whatever we determine is a common case. 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 )
[Zope-dev] Re: zcml entry points
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hey,
On 10/20/07, Lennart Regebro [EMAIL PROTECTED] wrote:
On 10/20/07, Martijn Faassen [EMAIL PROTECTED] wrote:
I'd say it is a general concern of a framework to try to avoid how often
you need to repeat yourself. Right now you to use a Zope 3 package you
need to do the following things:
* list the egg in your setup.py dependencies
* load the ZCML required
* import it in your code
True. But they do different things.
1. Says download and install a component
2. Says configure a component
3. Says use a component
Sure, they do different things. Nonetheless, there is repetition that
could be reduced. In fact
there's potentially a fourth place now where we reference dependency
information again:
4. Use this version of this component
(though this may be maintained outside of the actual package)
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.
setuptools spells that semantic so:
import pkg_resources
loaded = require('zope.interface 3.4.0')
At that point, the 'zope.interface' egg is guaranteed to be on sys.path,
and with the desired version: the subsequent:
import zope.interface
will then come from that location. This presumes that you haven't
already hacked sys.path to include it from somewhere else ('requires'
appends entries there).
Note that if 'grok' itself explicitly pins all its requirements (the
frozen egg scenario), then just saying:
pkg_resources.require('grok')
would have the effect of loading *all* the pinned requirements eggs onto
sys.path.
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.
But there is significant repetition spread out across the codebase.
It's not in one place, which forces a repetition in referring to the
component being installed/configured/imported. My response is to think
about ways to reduce this (while of course, looking for ways to retain
power and flexibility).
If you expose an 'entry point group for the automagic ZCML loader to
use, then you don't require any repetition in the client code, because
the plugin provide conforms to a standard interface which allows discovery::
# Assume that plugins register one or more entry points for the group,
# 'plone.automatic_zcml', where each entry point is a module name whose
# ZCML is to be loaded.
from zope.configuration.xmlconfig import xmlconfig
for ep in pkg_resources.iter_entry_points('plone.automatic_zcml'):
... module_name = ep.module_name
... # trigger ZCML loading here using 'module_name'
... stream = pkg_resources.resource_stream(module_name,
... 'configure.zcml')
... xmlconfig(stream)
[1]
http://peak.telecommunity.com/DevCenter/setuptools#dynamic-discovery-of-services-and-plugins
[2]
http://peak.telecommunity.com/DevCenter/PythonEggs#accessing-package-resources
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHHMDB+gerLs4ltQ4RAsGRAKCqpHz3HJjzlscWDAlrXnygKXlNIwCffSsn
aumELzdGgsHQoZDDPSPoTSw=
=GHqp
-END PGP SIGNATURE-
___
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 )
[Zope-dev] Re: zcml entry points
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Tres Seaver wrote: Wichert Akkerman wrote: [snip] So I turned things around: if I state in my egg information that I require another package that means I need to have that package available and functional. Which suggests that its zcml has to be loaded before mine. And that is exactly what I am doing: adding an entry point that allows a package to say in order to function I need to have these zcml files loaded. I may not *want* the other package's ZCML to be loaded: some of its policies may not be appropriate for my application. Since this appears to be a rare case that is the exception, what about using the new ZCML exclude framework for this case? You need to know what you are doing, but this use case is for people who know exactly what they're doing anyway, right? It isn't that rare: how many people want to turn off the Rotterdam skin in Z3, for instance? In general, the authors of a library package can't anticipate how their code will be used; the ZCML they provide is intended to cover the cases they know or imagine most people want. That probably depends a bit on how that package is created though. In an ideal world, Rotterdam would be a separate package (or packages) that could be pulled in or not (i.e. if you don't depend on it and/or you don't include its ZCML file and/or you use the zc.configure exclude behaviour to turn it off). ZCML represents policy, not mechanism, and hence is inherently less reusable than code. That is true, but how many people actually re-do all the ZCML for all the packages they use? Most packages, I imagine, will have been built with re-use in mind. They make appropriate use of adapters and marker interfaces and whatever else so that the user of the package has some control, or even an opt-out. But for most packages, I don't think there's going to be a host of different policies that are actually interesting. Put differently, in Plone we choose not to include various packages, but the ones we *do* use, we tend to use wholesale. We may override (or use a more-specific adapter for) some policy decisions, e.g. when it was written for zope 3 and we need some zope 2 magic, but up until now that's tended to be pretty manageable. I fully subscribe to the separation of policy and implementation (though I think in practice, policy is often something you override with specific adapters or utilities, not only expressed in ZCML), but I really hope that most Zope 3 developers don't end up reading, understanding and may reproducing every single line of ZCML in every single package they ever depend on. :) I think Jim's suggestion was good, though: Something like Plone or Grok - that want to be pluggable applications - could use an includeEntryPoints / type ZCML directive to process ZCML pulled in via entry points. Other packages may choose not to do that. Other packages again, may choose to do that but then use zc.configure to turn some stuff off, or just override whatever registrations they need. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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: zcml entry points
Martijn Faassen wrote at 2007-10-20 03:15 +0200: ... I'd say it is a general concern of a framework to try to avoid how often you need to repeat yourself. Right now you to use a Zope 3 package you need to do the following things: * list the egg in your setup.py dependencies * load the ZCML required * import it in your code Investigating ways to reduce this sounds like a win from a framework perspective. Getting rid of the separate ZCML step would help as it'd make it more similar to just reusing an arbitrary Python package, making Zope less special in some ways. Zope 2 had (for products) all three things together. It was felt that this was a too tight coupling. Therefore, for Zope 3 the paradigma explicit is better than implicit (a paradigma, that I personally dislike and find wrong) was used. Now, you want again more things to happen implicitly. In my view, this is natural -- but not in the Zope 3 spirit... -- 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 )
[Zope-dev] Re: zcml entry points
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Tres Seaver wrote: Wichert Akkerman wrote: [snip] So I turned things around: if I state in my egg information that I require another package that means I need to have that package available and functional. Which suggests that its zcml has to be loaded before mine. And that is exactly what I am doing: adding an entry point that allows a package to say in order to function I need to have these zcml files loaded. I may not *want* the other package's ZCML to be loaded: some of its policies may not be appropriate for my application. Since this appears to be a rare case that is the exception, what about using the new ZCML exclude framework for this case? You need to know what you are doing, but this use case is for people who know exactly what they're doing anyway, right? It isn't that rare: how many people want to turn off the Rotterdam skin in Z3, for instance? In general, the authors of a library package can't anticipate how their code will be used; the ZCML they provide is intended to cover the cases they know or imagine most people want. ZCML represents policy, not mechanism, and hence is inherently less reusable than code. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHGV1F+gerLs4ltQ4RAjRaAKCuDy247kYNF5Ol6T6lHl0EQWprCwCgmOoX eKcm7W1oh739digDWK0SG5g= =1y7d -END PGP SIGNATURE- ___ 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 )
[Zope-dev] Re: zcml entry points
Fred Drake wrote: On 10/17/07, Martin Aspeli [EMAIL PROTECTED] wrote: Right - but you're building an application, and you're pretty experienced with Zope. A lot of Plone users just want to install a plug-in (a product), basically. Before, they just dropped it into a It sounds like your concerns center around users of a pluggable/extensible application (like Plone), rather than being general Zope concerns. It's certainly reasonable for an application to want a plugin architecture that works that way. I'd say it is a general concern of a framework to try to avoid how often you need to repeat yourself. Right now you to use a Zope 3 package you need to do the following things: * list the egg in your setup.py dependencies * load the ZCML required * import it in your code Investigating ways to reduce this sounds like a win from a framework perspective. Getting rid of the separate ZCML step would help as it'd make it more similar to just reusing an arbitrary Python package, making Zope less special in some ways. Perhaps the development teams for the applications would be interested in getting together and sharing a package that supports a plugin architecture that works that way. That would be a good place to share effort without negatively impacting users who need bare-metal Zope or the developers of applications that don't have similar plugin-management requirements. Sure, we should always avoid negatively impacting people who want to repeat themselves in many places as they need the control in some places. :) That's a given constraint with the bare Zope 3 libraries we'll need to keep in mind always. The ability to not use this should be present, and I'm fine if the default is not to use this. Systems like Plone and Grok can always turn this on. 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 )
[Zope-dev] Re: zcml entry points
Tres Seaver wrote: Wichert Akkerman wrote: [snip] So I turned things around: if I state in my egg information that I require another package that means I need to have that package available and functional. Which suggests that its zcml has to be loaded before mine. And that is exactly what I am doing: adding an entry point that allows a package to say in order to function I need to have these zcml files loaded. I may not *want* the other package's ZCML to be loaded: some of its policies may not be appropriate for my application. Since this appears to be a rare case that is the exception, what about using the new ZCML exclude framework for this case? You need to know what you are doing, but this use case is for people who know exactly what they're doing anyway, right? 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 )
[Zope-dev] Re: zcml entry points
Hey, Martin Aspeli wrote: Fred Drake wrote: [snip] For example, say you want to install oi.plum. You need to add the line 'oi.plum' twice - once under 'eggs' and once under 'zcml' in your buildout.cfg. Forget the latter, and the package doesn't work properly (or at all). I actually really like this; I don't get the configuration for a package unless I ask for it. It's not unusual to want only the code and not the default configuration for a package. Right - but you're building an application, and you're pretty experienced with Zope. A lot of Plone users just want to install a plug-in (a product), basically. Before, they just dropped it into a directory. Now, they declare it twice in a file (presuming there's a cheese shop release). That's a (small) step backwards (duplication). Declaring it once would be a step forwards (no manual download) Right - if I understand this well, this would introduce the option not to have to repeat yourself. You use the egg and that takes care of loading the ZCML. Sounds like a good thing, as long as it can somehow be turned off. This would be a good thing for Grok to have. 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: zcml entry points
On Friday 19 October 2007 21:17, Martijn Faassen wrote: Tres Seaver wrote: I may not *want* the other package's ZCML to be loaded: some of its policies may not be appropriate for my application. +1. Happens to me all the time. Since this appears to be a rare case that is the exception, what about using the new ZCML exclude framework for this case? You need to know what you are doing, but this use case is for people who know exactly what they're doing anyway, right? -1. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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: zcml entry points
Martin Aspeli wrote: Fred Drake wrote: On 10/17/07, Wichert Akkerman [EMAIL PROTECTED] wrote: A common issue we are seeing is that we have eggs depending on each other, but they still need to load the zcml from those dependencies somehow. As a temporary solution to play with the concept I added something simple to the plone.recipe.zope2instance buildout recipe. What's the problem you're seeing? I'm not sure what you're trying to solve. ZCML includes work just fine in the egg world. As long as you're referring to packaged ZCML using package=package.name in your include and includeOverrides directives, all is good. The main win, IMHO, is to avoid the requirement for people to install slugs for third party products. Slugs suck - they are confusing to explain and people forget them all the time. Buildout makes it a bit easier, but it's still not a terribly good solution. For example, say you want to install oi.plum. You need to add the line 'oi.plum' twice - once under 'eggs' and once under 'zcml' in your buildout.cfg. Forget the latter, and the package doesn't work properly (or at all). I see a different win. At the moment we are declaring dependencies in two places: in the egg information and in the zcml files. For every package I need I need to make sure its zcml is loaded, which means I need to have a meta.zcml, configure.zcml and overrides.zcml which load the meta, configure and overrides from all packages I depend on. I also need to inspect every package I depend on to check if they have a meta, configure or overrides.zcml, which in my humble opinion should be just an implementation detail that I, as someone who is just using the zope stack/framework, should not need to know about. Multiply that with the number of dependencies you see in zope.* and you see this becomes very unwieldy. So I turned things around: if I state in my egg information that I require another package that means I need to have that package available and functional. Which suggests that its zcml has to be loaded before mine. And that is exactly what I am doing: adding an entry point that allows a package to say in order to function I need to have these zcml files loaded. Wichert. -- Wichert Akkerman [EMAIL PROTECTED] It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 )
[Zope-dev] Re: zcml entry points
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wichert Akkerman wrote: Martin Aspeli wrote: Fred Drake wrote: On 10/17/07, Wichert Akkerman [EMAIL PROTECTED] wrote: A common issue we are seeing is that we have eggs depending on each other, but they still need to load the zcml from those dependencies somehow. As a temporary solution to play with the concept I added something simple to the plone.recipe.zope2instance buildout recipe. What's the problem you're seeing? I'm not sure what you're trying to solve. ZCML includes work just fine in the egg world. As long as you're referring to packaged ZCML using package=package.name in your include and includeOverrides directives, all is good. The main win, IMHO, is to avoid the requirement for people to install slugs for third party products. Slugs suck - they are confusing to explain and people forget them all the time. Buildout makes it a bit easier, but it's still not a terribly good solution. For example, say you want to install oi.plum. You need to add the line 'oi.plum' twice - once under 'eggs' and once under 'zcml' in your buildout.cfg. Forget the latter, and the package doesn't work properly (or at all). I see a different win. At the moment we are declaring dependencies in two places: in the egg information and in the zcml files. For every package I need I need to make sure its zcml is loaded, which means I need to have a meta.zcml, configure.zcml and overrides.zcml which load the meta, configure and overrides from all packages I depend on. I also need to inspect every package I depend on to check if they have a meta, configure or overrides.zcml, which in my humble opinion should be just an implementation detail that I, as someone who is just using the zope stack/framework, should not need to know about. Multiply that with the number of dependencies you see in zope.* and you see this becomes very unwieldy. So I turned things around: if I state in my egg information that I require another package that means I need to have that package available and functional. Which suggests that its zcml has to be loaded before mine. And that is exactly what I am doing: adding an entry point that allows a package to say in order to function I need to have these zcml files loaded. I may not *want* the other package's ZCML to be loaded: some of its policies may not be appropriate for my application. I think that the library vs. pluggable application distinction is valid here: maybe you want to define an entry point in the egg which a given pluggable app would use at startup time to configure all the plugins which exposed that entry point. Five fakes such an entry point now by implicitly loading meta.zcml, then configure.zcml, then overrides.zcml for all packages it recognizes as products: are you proposing to replace Five's DWIM with a new, explicit version? Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFHF07w+gerLs4ltQ4RApigAJQKD7QktS+kRjxD3XiJ76p/QEjXAKCuhpNk oKng4r5TQOJiuL9WFZst0A== =91pF -END PGP SIGNATURE- ___ 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: zcml entry points
On Oct 17, 2007, at 8:04 PM, Ross Patterson wrote: ... I'm new to eggs, but maybe both sides could be satisfied with an approach like extra_requires? Extras are evil. See other posts of mine for explanations of why. You could list oi.plum [zope.zcml] when you require oi.plum *and* its ZCML and then it's ZCML would get loaded. Is this easily possible with eggs and/or buildout? easy_install has nothing to do with loading ZCML. A recipe could do something, but extra-requires don't help in any useful way. Jim -- Jim Fulton Zope Corporation ___ 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 )
[Zope-dev] Re: zcml entry points
Tres Seaver wrote: I may not *want* the other package's ZCML to be loaded: some of its policies may not be appropriate for my application. I think that the library vs. pluggable application distinction is valid here: maybe you want to define an entry point in the egg which a given pluggable app would use at startup time to configure all the plugins which exposed that entry point. +1 Five fakes such an entry point now by implicitly loading meta.zcml, then configure.zcml, then overrides.zcml for all packages it recognizes as products: are you proposing to replace Five's DWIM with a new, explicit version? That may be preferable, but quite hard from a BBB perspective. Right now all kinds of products exist that just expect their ZCML to be automagically loaded. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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: zcml entry points
On Oct 18, 2007, at 8:17 AM, Tres Seaver wrote: I may not *want* the other package's ZCML to be loaded: some of its policies may not be appropriate for my application. I think that the library vs. pluggable application distinction is valid here: maybe you want to define an entry point in the egg which a given pluggable app would use at startup time to configure all the plugins which exposed that entry point. This probably an indication that there are two (I know, that horrible number) types of packages: - packages which provide zcml sugar in the form of new directive definitions - packages which perform component registrations It seems that packages which do only the former could be classified as a true library while the latter is more application-y. It seems like in a perfect world, libraries should not need any configure.zcml, just a meta.zcml which contains little except meta directives. Personally I think it would be more useful to remove policy-laden registrations from existing packages so they're more libraryish and move these registrations into site.zcml (or an entry point moral equivalent) than it would be to attempt to annoint the status quo as the right thing by implementing dependency graph traversal. - 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 )
[Zope-dev] Re: zcml entry points
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Aspeli wrote: Tres Seaver wrote: I may not *want* the other package's ZCML to be loaded: some of its policies may not be appropriate for my application. I think that the library vs. pluggable application distinction is valid here: maybe you want to define an entry point in the egg which a given pluggable app would use at startup time to configure all the plugins which exposed that entry point. +1 Five fakes such an entry point now by implicitly loading meta.zcml, then configure.zcml, then overrides.zcml for all packages it recognizes as products: are you proposing to replace Five's DWIM with a new, explicit version? That may be preferable, but quite hard from a BBB perspective. Right now all kinds of products exist that just expect their ZCML to be automagically loaded. I'm not arguing against preserving the majyk done for things Zope2 calls 'Products'; however, I don't want to extend the majyk any further. I would also be fine with adding a new directive which caused explicit triggering of introspected ZCML, e.g.: !-- Load ZCML from all packages which register a 'meta.zcml' entry point -- majyk entry_point=meta.zcml / !-- Load ZCML from all packages which register a 'configure.zcml' entry point -- majyk entry_point=configure.zcml / I *really* don't see the point, by the way, in automagically running 'overrides.zcml' from products: by definition, the reusable package author doesn't know enough to override declarations made by other reusable packages. If a site manager wants to configure overides, then adding them manually to her site.zcml should be fine. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHF5mM+gerLs4ltQ4RAu1+AJ0RtIXJaedfzgEXbL+5cjYDNJI+rQCfRCtY 9DqQBllKGsr7wMAjVW6WQWA= =Yl5B -END PGP SIGNATURE- ___ 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 )
[Zope-dev] Re: zcml entry points
Fred Drake wrote: On 10/17/07, Wichert Akkerman [EMAIL PROTECTED] wrote: A common issue we are seeing is that we have eggs depending on each other, but they still need to load the zcml from those dependencies somehow. As a temporary solution to play with the concept I added something simple to the plone.recipe.zope2instance buildout recipe. What's the problem you're seeing? I'm not sure what you're trying to solve. ZCML includes work just fine in the egg world. As long as you're referring to packaged ZCML using package=package.name in your include and includeOverrides directives, all is good. The main win, IMHO, is to avoid the requirement for people to install slugs for third party products. Slugs suck - they are confusing to explain and people forget them all the time. Buildout makes it a bit easier, but it's still not a terribly good solution. For example, say you want to install oi.plum. You need to add the line 'oi.plum' twice - once under 'eggs' and once under 'zcml' in your buildout.cfg. Forget the latter, and the package doesn't work properly (or at all). If we had entry points, we could just load the egg. Internally, oi.plum may use include / as much as necessary to load *its* dependencies, but that's not something the user of the package needs to worry about. If Zope loaded entry-point ZCML automatically (maybe with an on/off switch in zope.conf for those who need more fine grained control) that'd be a pretty nice solution. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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: zcml entry points
On 10/17/07, Martin Aspeli [EMAIL PROTECTED] wrote: The main win, IMHO, is to avoid the requirement for people to install slugs for third party products. Slugs suck - they are confusing to explain and people forget them all the time. Buildout makes it a bit easier, but it's still not a terribly good solution. Slugs are evil; agreed. We never use them. They were an accident of the instance tree inherited from older versions of Zope, and how that tree was re-interpreted for Zope 3. They never worked well, and did no one any favors. For example, say you want to install oi.plum. You need to add the line 'oi.plum' twice - once under 'eggs' and once under 'zcml' in your buildout.cfg. Forget the latter, and the package doesn't work properly (or at all). I actually really like this; I don't get the configuration for a package unless I ask for it. It's not unusual to want only the code and not the default configuration for a package. If we had entry points, we could just load the egg. Internally, oi.plum may use include / as much as necessary to load *its* dependencies, but that's not something the user of the package needs to worry about. Requiring a package doesn't say anything about how it's going to be used; making an assumption about that is really bad. If Zope loaded entry-point ZCML automatically (maybe with an on/off switch in zope.conf for those who need more fine grained control) that'd be a pretty nice solution. I suspect I'd always want it off. Picking up configuration willy-nilly is too dangerous. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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 )
[Zope-dev] Re: zcml entry points
Fred Drake wrote: On 10/17/07, Martin Aspeli [EMAIL PROTECTED] wrote: The main win, IMHO, is to avoid the requirement for people to install slugs for third party products. Slugs suck - they are confusing to explain and people forget them all the time. Buildout makes it a bit easier, but it's still not a terribly good solution. Slugs are evil; agreed. We never use them. They were an accident of the instance tree inherited from older versions of Zope, and how that tree was re-interpreted for Zope 3. They never worked well, and did no one any favors. Glad we all agree. For example, say you want to install oi.plum. You need to add the line 'oi.plum' twice - once under 'eggs' and once under 'zcml' in your buildout.cfg. Forget the latter, and the package doesn't work properly (or at all). I actually really like this; I don't get the configuration for a package unless I ask for it. It's not unusual to want only the code and not the default configuration for a package. Right - but you're building an application, and you're pretty experienced with Zope. A lot of Plone users just want to install a plug-in (a product), basically. Before, they just dropped it into a directory. Now, they declare it twice in a file (presuming there's a cheese shop release). That's a (small) step backwards (duplication). Declaring it once would be a step forwards (no manual download) If we had entry points, we could just load the egg. Internally, oi.plum may use include / as much as necessary to load *its* dependencies, but that's not something the user of the package needs to worry about. Requiring a package doesn't say anything about how it's going to be used; making an assumption about that is really bad. Maybe. I agree there should be an option not to do this, and many eggs may choose *not* to use an entry point. For things like Plone add-on products, though, it makes much more sense to have it be automatic. To generalise further - if what you're installing is a high level, cohesive product, with a UI and an install method and all the rest of it, having installation be as simple as possible is a big win. For the components further down the stack (e.g. the things that these high level products are depending on!), having the processing be explicit (via include / directives) makes more sense. If Zope loaded entry-point ZCML automatically (maybe with an on/off switch in zope.conf for those who need more fine grained control) that'd be a pretty nice solution. I suspect I'd always want it off. Picking up configuration willy-nilly is too dangerous. Maybe it's off by default, then, but I *know* this would make the add-on products story in Plone easier: I've seen people struggle with slugs, editing site.zcml is far tto scary, and you don't always have a package that you own to include other things from. I suspect entry points would make life simpler for other systems that used a similar mechanism for plug-ins/add-ons. However, I agree that they're not appropriate for more fundamental libraries. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ 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 )
[Zope-dev] Re: zcml entry points
Martin Aspeli [EMAIL PROTECTED] writes: Fred Drake wrote: On 10/17/07, Martin Aspeli [EMAIL PROTECTED] wrote: The main win, IMHO, is to avoid the requirement for people to install slugs for third party products. Slugs suck - they are confusing to explain and people forget them all the time. Buildout makes it a bit easier, but it's still not a terribly good solution. Slugs are evil; agreed. We never use them. They were an accident of the instance tree inherited from older versions of Zope, and how that tree was re-interpreted for Zope 3. They never worked well, and did no one any favors. Glad we all agree. For example, say you want to install oi.plum. You need to add the line 'oi.plum' twice - once under 'eggs' and once under 'zcml' in your buildout.cfg. Forget the latter, and the package doesn't work properly (or at all). I actually really like this; I don't get the configuration for a package unless I ask for it. It's not unusual to want only the code and not the default configuration for a package. Right - but you're building an application, and you're pretty experienced with Zope. A lot of Plone users just want to install a plug-in (a product), basically. Before, they just dropped it into a directory. Now, they declare it twice in a file (presuming there's a cheese shop release). That's a (small) step backwards (duplication). Declaring it once would be a step forwards (no manual download) If we had entry points, we could just load the egg. Internally, oi.plum may use include / as much as necessary to load *its* dependencies, but that's not something the user of the package needs to worry about. Requiring a package doesn't say anything about how it's going to be used; making an assumption about that is really bad. Maybe. I agree there should be an option not to do this, and many eggs may choose *not* to use an entry point. For things like Plone add-on products, though, it makes much more sense to have it be automatic. To generalise further - if what you're installing is a high level, cohesive product, with a UI and an install method and all the rest of it, having installation be as simple as possible is a big win. For the components further down the stack (e.g. the things that these high level products are depending on!), having the processing be explicit (via include / directives) makes more sense. If Zope loaded entry-point ZCML automatically (maybe with an on/off switch in zope.conf for those who need more fine grained control) that'd be a pretty nice solution. I suspect I'd always want it off. Picking up configuration willy-nilly is too dangerous. Maybe it's off by default, then, but I *know* this would make the add-on products story in Plone easier: I've seen people struggle with slugs, editing site.zcml is far tto scary, and you don't always have a package that you own to include other things from. I suspect entry points would make life simpler for other systems that used a similar mechanism for plug-ins/add-ons. However, I agree that they're not appropriate for more fundamental libraries. I'm new to eggs, but maybe both sides could be satisfied with an approach like extra_requires? You could list oi.plum [zope.zcml] when you require oi.plum *and* its ZCML and then it's ZCML would get loaded. Is this easily possible with eggs and/or buildout? If not, maybe it's a worthwhile extension. I guess the abstracted idea would be some way to pass configuration directives to eggs as a part of requiring them. Ross ___ 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: zcml entry points
On 10/17/07, Martin Aspeli [EMAIL PROTECTED] wrote: Right - but you're building an application, and you're pretty experienced with Zope. A lot of Plone users just want to install a plug-in (a product), basically. Before, they just dropped it into a It sounds like your concerns center around users of a pluggable/extensible application (like Plone), rather than being general Zope concerns. It's certainly reasonable for an application to want a plugin architecture that works that way. Perhaps the development teams for the applications would be interested in getting together and sharing a package that supports a plugin architecture that works that way. That would be a good place to share effort without negatively impacting users who need bare-metal Zope or the developers of applications that don't have similar plugin-management requirements. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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 )
[Zope-dev] Re: zcml entry points
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wichert Akkerman wrote:
A common issue we are seeing is that we have eggs depending on each
other, but they still need to load the zcml from those dependencies
somehow. As a temporary solution to play with the concept I added
something simple to the plone.recipe.zope2instance buildout recipe.
It allows you to define entrypoints like this:
entry_points={
zope.zcml : [
meta = plone.session,
configure = plone.session,
],
},
this tells the system to load meta.zcml and configure.zcml from plone.session.
I am not quite sure what the best way to hook this into Zope itself is.
For Zope 2 we can do it in Five, since that is where all the zcml loading
logic currently is. Or we could move that into Zope2 itself somewhere.
I'm not familiar enough with Zope3 to know what the best place would be there.
One problem is ordering: the zope.component zcml needs to be loaded first.
That's a packaging bug: any package whose ZCML won't load without
having zope.component loaded already needs to add the explicit inclusion
(duplicates do *not* conflict for the include directive).
Perhaps we need to build an egg dependency graph and walk through that
to load zcml entry points in the right order. As long as all dependencies
are registered correctly that should work.
I'd rather fix the ZCML files.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHFstL+gerLs4ltQ4RAnE+AKCeuEvcOW9P9BKMXJ0lJE5dxRtorwCfXgXO
Md2MbCD/PGIClJ/cvmJPeE4=
=Ti55
-END PGP SIGNATURE-
___
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 )
[Zope-dev] Re: ZCML and 'zopectl test'?
Andreas Jung wrote: I added Products/PageTemplates/configure.zcml to register an utility. That works fine when running Zope however zopectl test won't work properly anymore because the utility registration does not seem to happen when running the tests. Bug or feature? Tests need to do their own setup. ZCML isn't magically loaded for tests, unless those tests are run within a layer that loads all ZCML before running the tests. So, there are two options: - modify the setUp() of the tests in question to provideUtility(your_utility) - make the respective tests run in a layer that loads the ZCML. I don't think layer support is on the trunk yet. Whit Morriss has a branch where he added that to Zope 2, but it still hasn't been merged :( Philipp -- http://worldcookery.com -- Professional Zope documentation and training 2nd edition of Web Component Development with Zope 3 is now shipping! ___ 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: ZCML and 'zopectl test'?
On Sun, Jan 07, 2007 at 12:14:32PM +0100, Philipp von Weitershausen wrote: So, there are two options: - modify the setUp() of the tests in question to provideUtility(your_utility) - make the respective tests run in a layer that loads the ZCML. I don't think layer support is on the trunk yet. Whit Morriss has a branch where he added that to Zope 2, but it still hasn't been merged :( The testrunner in zope 2 has supported layers for quite a while. I currently use layers in my tests with zope 2.9.1. TestLayersHowTo on zopewiki.org gives a working example. Or do you mean something else by layer support? -- Paul Winkler ___ 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 )
[Zope-dev] Re: ZCML and 'zopectl test'?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Andreas Jung wrote: I added Products/PageTemplates/configure.zcml to register an utility. That works fine when running Zope however zopectl test won't work properly anymore because the utility registration does not seem to happen when running the tests. Bug or feature? Tests need to do their own setup. ZCML isn't magically loaded for tests, unless those tests are run within a layer that loads all ZCML before running the tests. So, there are two options: - modify the setUp() of the tests in question to provideUtility(your_utility) - make the respective tests run in a layer that loads the ZCML. I don't think layer support is on the trunk yet. Whit Morriss has a branch where he added that to Zope 2, but it still hasn't been merged :( I'm pretty sure that layer support is on the 2.10 branch and the trunk: the CMF trunk tests now depend on it:: $ bin/zopectl show zdctl/zdrun options: schemafile: '/home/tseaver/projects/Zope-CVS/Zope-2.10-branch/lib/python/Zope2/Startup/zopeschema.xml' ... $ bin/zopectl test Running tests via: /home/tseaver/projects/Zope-CVS/bin/python2.4 /home/tseaver/projects/Zope-CVS/Zope-2.10-branch/bin/test.py -v - --config-file /home/tseaver/projects/CMF/cmf_test/z210_cmfhead/etc/zope.conf Parsing /home/tseaver/projects/CMF/cmf_test/z210_cmfhead/etc/zope.conf Running tests at level 1 Running unit tests: Running: . Ran 809 tests with 0 failures and 0 errors in 11.052 seconds. Running Products.CMFCore.testing.FunctionalZCMLLayer tests: Set up Products.CMFCore.testing.FunctionalZCMLLayer in 1.603 seconds. ... Tearing down left over layers: Tear down Products.GenericSetup.testing.ExportImportZCMLLayer in 0.000 seconds. Total: 1351 tests, 0 failures, 0 errors Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFoU2z+gerLs4ltQ4RAmxhAKDUo3oEHv8bUIoW/dLMmpeHvMWvdACgy1wU 0P+mwfqR/0MVCICtu5AZ568= =fuE+ -END PGP SIGNATURE- ___ 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 )
[Zope-dev] Re: ZCML and 'zopectl test'?
On 7 Jan 2007, at 20:44 , Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Andreas Jung wrote: I added Products/PageTemplates/configure.zcml to register an utility. That works fine when running Zope however zopectl test won't work properly anymore because the utility registration does not seem to happen when running the tests. Bug or feature? Tests need to do their own setup. ZCML isn't magically loaded for tests, unless those tests are run within a layer that loads all ZCML before running the tests. So, there are two options: - modify the setUp() of the tests in question to provideUtility(your_utility) - make the respective tests run in a layer that loads the ZCML. I don't think layer support is on the trunk yet. Whit Morriss has a branch where he added that to Zope 2, but it still hasn't been merged :( I'm pretty sure that layer support is on the 2.10 branch and the trunk: the CMF trunk tests now depend on it:: I phrased that wrongly. Layer support from the test runner perspective is in Zope 2 since Zope 2.9. But Zope 2 itself actually using test layers is not in any release branch. $ bin/zopectl show zdctl/zdrun options: schemafile: '/home/tseaver/projects/Zope-CVS/Zope-2.10-branch/lib/python/Zope2/ Startup/zopeschema.xml' ... $ bin/zopectl test Running tests via: /home/tseaver/projects/Zope-CVS/bin/python2.4 /home/tseaver/projects/Zope-CVS/Zope-2.10-branch/bin/test.py -v - --config-file /home/tseaver/projects/CMF/cmf_test/z210_cmfhead/etc/zope.conf Parsing /home/tseaver/projects/CMF/cmf_test/z210_cmfhead/etc/zope.conf Running tests at level 1 Running unit tests: Running: .. .. .. .. .. .. .. .. .. .. .. ... Ran 809 tests with 0 failures and 0 errors in 11.052 seconds. Running Products.CMFCore.testing.FunctionalZCMLLayer tests: Set up Products.CMFCore.testing.FunctionalZCMLLayer in 1.603 seconds. ... Tearing down left over layers: Tear down Products.GenericSetup.testing.ExportImportZCMLLayer in 0.000 seconds. Total: 1351 tests, 0 failures, 0 errors Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFoU2z+gerLs4ltQ4RAmxhAKDUo3oEHv8bUIoW/dLMmpeHvMWvdACgy1wU 0P+mwfqR/0MVCICtu5AZ568= =fuE+ -END PGP SIGNATURE- ___ 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 )
[Zope-dev] Re: ZCML and 'zopectl test'?
I just made ZopeTestCase defer all loading until it's layer(essentially deferring the import of ZopeLite which is sort of a subpar way to handle things and using a registry to handle installProducts). most of what happens in zopelite itself should be the layer(rather than carefully isolating the import) http://svn.zope.org/Zope/branches/whitmo-2.10-layers/ lurker, comments? from what I remember, the only issue was with the sandbox tests(for functional tests). basically in sandboxed test you need a fresh zodb for each test iirc. -w ___ 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] To ZCML or not ;-)
Martijn Faassen wrote: Anyway, while I have my criticisms of ZCML, too much typing is really not very important in my list. You can get it somewhat shorter, I'm sure, but not *that* much shorter. I'd worry more about the reading part than the writing. More typing = more reading in my books, so I guess we're in agreement ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] To ZCML or not ;-)
Stephan Richter wrote: Can you be more specific? I think ZCML is very compact. Well, I'm hoping to take a proper look at the latest Z3 some time soon, so I'll let you know after that and shut up on the subject in the meantime ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] To ZCML or not ;-)
Lennart Regebro wrote: You know the feeling when a third party product has the wrong permission or no permission at all on something? What are you gonna do? Subclass: Lots of work. Patch: You gotta keep it updated. With ZCML, you override it. TADA! Yes, this is all stuff I know and love about Z3 ;-) When I last saw ZCML, it was horrible though. I don't mind XML, just not if it lots of pointless typing... Jim suggests that ZCML has got better, I hope so, in which case I won't have to write an alternative that uses the same underlying infrastructure :-D cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] To ZCML or not ;-)
Chris Withers wrote: Lennart Regebro wrote: You know the feeling when a third party product has the wrong permission or no permission at all on something? What are you gonna do? Subclass: Lots of work. Patch: You gotta keep it updated. With ZCML, you override it. TADA! Yes, this is all stuff I know and love about Z3 ;-) When I last saw ZCML, it was horrible though. I don't mind XML, just not if it lots of pointless typing... Jim suggests that ZCML has got better, I hope so, in which case I won't have to write an alternative that uses the same underlying infrastructure :-D Since ZML is XML, creating a less verbose language may be easier to accomplish by actually *using* the XML infrastructure, and translating your language to ZCML. Anyway, while I have my criticisms of ZCML, too much typing is really not very important in my list. You can get it somewhat shorter, I'm sure, but not *that* much shorter. I'd worry more about the reading part than the writing. 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] To ZCML or not ;-)
On Apr 8, 2005 12:54 PM, Martijn Faassen [EMAIL PROTECTED] wrote: Chris Withers wrote: Lennart Regebro wrote: You know the feeling when a third party product has the wrong permission or no permission at all on something? What are you gonna do? Subclass: Lots of work. Patch: You gotta keep it updated. With ZCML, you override it. TADA! Yes, this is all stuff I know and love about Z3 ;-) When I last saw ZCML, it was horrible though. I don't mind XML, just not if it lots of pointless typing... Jim suggests that ZCML has got better, I hope so, in which case I won't have to write an alternative that uses the same underlying infrastructure :-D Since ZML is XML, creating a less verbose language may be easier to accomplish by actually *using* the XML infrastructure, and translating your language to ZCML. Anyway, while I have my criticisms of ZCML, too much typing is really not very important in my list. You can get it somewhat shorter, I'm sure, but not *that* much shorter. I'd worry more about the reading part than the writing. Yeah, I mean: something:something foo=bar frotz=fnyppel fingal:ohlsson bitbucket=buccaneer / /something:something Is not significantly shorter than: something/something: foo=bar frotz=fnyppel fingal/ohlsson: bitbucket=buccaneer Which would be really a minimal/shortest way to write it. For me, the main drawback with ZCML is that WingIDE doesn't to auto completion on it. ;) An ZCML editor that automatically popped up a list of the supported keywords for every statement would be really nice. :-p A benefit of using an XML format is that many editors will happily both do syntax high-lighting, some sort of auto-indentation, and automatic commenting/uncommenting. A non-standard syntax wouldn't do that. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] To ZCML or not ;-)
Lennart Regebro wrote: On Apr 8, 2005 12:54 PM, Martijn Faassen [EMAIL PROTECTED] wrote: ... A benefit of using an XML format is that many editors will happily both do syntax high-lighting, some sort of auto-indentation, and automatic commenting/uncommenting. A non-standard syntax wouldn't do that. Speaking of which, a nice little project for someone would be to write a generator to generate RelaxNG schemas from ZCML meta configuration. Then XML editors could provide more help with the editing, possibly including hings like autocompletion. This should be a realtively easy task in that apidoc already has code for extracting documentation from meta configuration. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] To ZCML or not ;-)
On Friday 08 April 2005 03:24, Chris Withers wrote: Yes, this is all stuff I know and love about Z3 ;-);-) When I last saw ZCML, it was horrible though. I don't mind XML, just not if it lots of pointless typing... Can you be more specific? I think ZCML is very compact. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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] To ZCML or not ;-)
On Friday 08 April 2005 07:34, Lennart Regebro wrote: For me, the main drawback with ZCML is that WingIDE doesn't to auto completion on it. ;) An ZCML editor that automatically popped up a list of the supported keywords for every statement would be really nice. :-p: Yeah, I talked to Stephan and John about that already. Using Wing's new plugin architecture, it should be possible to insert such functionality. Another good application for the plugin system would be the recognition of interfaces by showing the interface documentation of a class implementing a certain interface. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ 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] To ZCML or not ;-)
On Apr 8, 2005 3:09 PM, Stephan Richter [EMAIL PROTECTED] wrote: On Friday 08 April 2005 07:34, Lennart Regebro wrote: For me, the main drawback with ZCML is that WingIDE doesn't to auto completion on it. ;) An ZCML editor that automatically popped up a list of the supported keywords for every statement would be really nice. :-p: Yeah, I talked to Stephan and John about that already. Using Wing's new plugin architecture, it should be possible to insert such functionality. Another good application for the plugin system would be the recognition of interfaces by showing the interface documentation of a class implementing a certain interface. Cool, that's good news. I won't have time to do it for the forseeable future though... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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] To ZCML or not ;-)
Lennart Regebro wrote: [snip] For me, the main drawback with ZCML is that WingIDE doesn't to auto completion on it. ;) An ZCML editor that automatically popped up a list of the supported keywords for every statement would be really nice. :-p Actually emacs + nxml + the Relax NG schema (unfortunately out of date; it should be autogenerated from the code) for ZCML does that. A benefit of using an XML format is that many editors will happily both do syntax high-lighting, some sort of auto-indentation, and automatic commenting/uncommenting. A non-standard syntax wouldn't do that. Yup, and if you use some XML editor (or an XML editor extension for your favorite editor) it can do quite sophisticated schema-driven stuff. 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 )
[Zope-dev] To ZCML or not ;-)
Richard Jones wrote: Is this a general trend for Zope 2? I'd rather see Zope 2 kinda avoid ZCML if possible. It's just one of those personal preference things, I suppose, but I know I'm not the only one who isn't that enamored of the ZCML approach. I actually like having the declarations all in the python code like it is in Zope 2. Am I right in thinking that the XML part of ZCML is layered over python functionality underneath? If so, how hard would it be to provide an alternative to the baroque XML? - the bit of ZCML I don't like ;-) cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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] To ZCML or not ;-)
Chris Withers wrote: Richard Jones wrote: Is this a general trend for Zope 2? I'd rather see Zope 2 kinda avoid ZCML if possible. It's just one of those personal preference things, I suppose, but I know I'm not the only one who isn't that enamored of the ZCML approach. I actually like having the declarations all in the python code like it is in Zope 2. Am I right in thinking that the XML part of ZCML is layered over python functionality underneath? If so, how hard would it be to provide an alternative to the baroque XML? - the bit of ZCML I don't like ;-) It's is theoretically possible, but not really worth the effort. I'll note that ZCML has gotten progressively simpler over the years. It continues to get simpler. For example, now that we we can say more about adapters in Python, a typical adapter registration looks like: adapter factory=.Myfactory / Also, for various reasons, ZCML took on implementation capabilities. We're looking at ways to move that implementation capability back into Python, where it belongs, which will make page definition easier. I expect that page definitions in the future will look more like: page name=foo.html class=.FooView.html permission=zope.View / Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ 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] To ZCML or not ;-)
Richard Jones wrote: Is this a general trend for Zope 2? I'd rather see Zope 2 kinda avoid ZCML if possible. It's just one of those personal preference things, I suppose, but I know I'm not the only one who isn't that enamored of the ZCML approach. ZCML started out for me (and as an experinced zope2 programmer I guess the experience may not be that unusual) as ooh, my, lots to learn, why is it that complex? Then it becames oh, it's a consistent way of doing all those thinks that weren't very pythonic, like defining page templates, and then finally I grasped it with ah, it's really the best parts of aspect orientation; you make all these separate modules, and you tie them together with ZCML! Like XML or not, the approach of moving this type of meta-information to ZCML rocks. You know the feeling when a third party product has the wrong permission or no permission at all on something? What are you gonna do? Subclass: Lots of work. Patch: You gotta keep it updated. With ZCML, you override it. TADA! ___ 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 )
