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 )
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 )
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 )
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 )
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 )
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 )
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 )
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 )
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 )
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 )
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 )
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 )
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 )
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 )