Re: [Zope3-dev] Re: zcml questions
Jim Fulton wrote: That's pretty much what I suggested. The whole point of discriminators was conflict detection. That is why I suggested extending actions to support identifiers that could be used for overriding or disabling even for actions (or groups of actions) that don't otherwise conflict. This id scheme would leverage discriminators when present. Sounds cool, I only wish I could offer to help make it happen :-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zcml questions
Jim Fulton wrote: Oh, so some directives have descriminators and others don't? Yes. Most do. Soe don't because they don't create actions that conflict with anything else. Ah, OK. Would it cause any problems to have all actions generate descriminators and only use them for conflict checking for actions that should do so? Yep. Would that cover the devmode use case and allow the deprecation of the crazy condition stuff? ;-) I doubt it. Shame... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zcml questions
Jim Fulton wrote: I definately want to make it possible for people to specify actions in Python. Me too :-) Not necessarily. actions already have discriminators which are, essentially ids. How do they work? Where can I see examples? What's needed is a way of assigning ids to directives, mainly subscriber definitions, that don't have discriminators. Oh, so some directives have descriminators and others don't? I also think it would be useful to be able to assign ids to groups of configuration to make it easier to disable a collection of things that go together. Yep. Would that cover the devmode use case and allow the deprecation of the crazy condition stuff? ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zcml questions
On Sep 26, 2006, at 5:54 AM, Chris Withers wrote: Jim Fulton wrote: Not necessarily. actions already have discriminators which are, essentially ids. How do they work? They are used to determine if actions conflict. They arethe basis of conflict detection and overriding. Where can I see examples? In the zope configuration doc tests. What's needed is a way of assigning ids to directives, mainly subscriber definitions, that don't have discriminators. Oh, so some directives have descriminators and others don't? Yes. Most do. Soe don't because they don't create actions that conflict with anything else. I also think it would be useful to be able to assign ids to groups of configuration to make it easier to disable a collection of things that go together. Yep. Would that cover the devmode use case and allow the deprecation of the crazy condition stuff? ;-) I doubt it. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zcml questions
Martijn Faassen wrote: configuration. This way, if we grow Python-based configuration or automatic configuration, the system will still work. I do care about this, because I hate zcml(tm) but how would you see disabling working in a python-based config? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zcml questions
Stephan Richter wrote: This has been proposed and approved, but implementation has been delayed due to missing XPath features. http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZCMLEnhancements I like all of the ideas on there, I'm a little confused though. How much of what is on there is actually implemented and where? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zcml questions
Jim Fulton wrote: I have a feeling that xpath is overkill. I wish it was, but I don't think it is.. It alsoi won't work for actions defined in Python. Wasn't aware you could do this, where can I find examples? I'd rather see some sort of identifier system. But that would mean every piece of zcml would need to have an id manually assigned as in id with the assigner ensuring that it's unique. This seems burdensome, xpath feels right here, at least imh(umble)o. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zcml questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: On Sep 25, 2006, at 1:44 PM, Chris Withers wrote: Jim Fulton wrote: It would *also* require that we implement the no side-effects during parsing policy (my other favorite dead horse in arguments about ZCML's implementation / usage). Beat away. :) I've been in favor of this for some time. This is definitely a goal. Can we have a papal edict that zcml that has side effects is a bug? (including the dotted name thing...) No, but I'm definitely in favor of refactoring existing handlers so they do pretty much all of their work in the actions they generate. We'll need to remove the parse-time error checking of name resolution then, which means storing filename / line number information with each dotted name so that the failed resolution can be reported when actions are running. Tres. - -- === Tres Seaver +1 202-558-7113 [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 iD8DBQFFGCT3+gerLs4ltQ4RAjubAKCAx3bjFDTQIJP2+NljAPNQJcwyYACglvno K4C1uDLz8e4M2MvIy1+w2TA= =srEr -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zcml questions
Jim Fulton wrote: On Sep 21, 2006, at 11:31 AM, Stephan Richter wrote: [snip] This has been proposed and approved, but implementation has been delayed due to missing XPath features. http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZCMLEnhancements I have a feeling that xpath is overkill. It alsoi won't work for actions defined in Python. Not hindered by much actual knowledge about this proposal, I share your feeling. It seems to imply working on the level of XML while we want to have something that's working on the semantic level of Zope configuration. This way, if we grow Python-based configuration or automatic configuration, the system will still work. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zcml questions
On Sep 22, 2006, at 5:06 AM, Martijn Faassen wrote: Jim Fulton wrote: On Sep 21, 2006, at 11:31 AM, Stephan Richter wrote: [snip] This has been proposed and approved, but implementation has been delayed due to missing XPath features. http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ ZCMLEnhancements I have a feeling that xpath is overkill. It alsoi won't work for actions defined in Python. Not hindered by much actual knowledge about this proposal, I share your feeling. It seems to imply working on the level of XML while we want to have something that's working on the semantic level of Zope configuration. This way, if we grow Python-based configuration or automatic configuration, the system will still work. Yes (or even an alternate configuration language, which I'm not proposing :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zcml questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Chris Withers wrote: Philipp von Weitershausen wrote: AFAIK, getUtilitiesFor is not supposed to order these in any way. While the returned iterator does find them in a reproduceable order due to the implementation, you shouldn't rely on that. OK, so you should always sort this list when using it for a UI? If you explicitly want the list to be sorted, sure. The question is how you want it to be sorted. Perhaps not everyone wants it to be sorted by the utility name. Also, getUtilitiesFor is a generator. That makes it efficient if you just get a few utilities, realize you have the one you want and don't get the rest. If you expect a sorted output, you lose that efficiency. Hmm, seems odd, is getUtilitiesFor used for anything other than generating UI's? I can't say off of the top of my head. Why don't you grep :) Also, if a site administrator wanted to unregister one of these in site.zcml, maybe because they didn't want the Traverse executor to be available, how would they go about doing that? ZCML has no way of unregistering specific utilities or adapters (though there's a Python API). That sucks :-( I thought the whole point of ZCML was that a site manager could override setup in site.zcml. 50% of that aim isn't done if they can't turn stuff off as well as on... Right. I think zcml:condition was a first step into that direction. Its implementation was very use case-driven. It seems you have a use case for more control over ZCML, so it'd be nice to hear from suggestions how you would envision a directive disabling feature in ZCML. Where can the python api for unregistration be found? On site managers. They have unregister* methods. So, *after* your ZCML has been loaded, you could poke at the global site manager and unregister the utilities that ZCML registered. In ZCML we typically define features and apply a condition using the feature: Why? So you can have yet another (pointless in this case) layer of indirection?! *sigh* We use it quite well in Zope 3 to enable/disable development tools like APIDoc. We have a feature called 'devmode' so all debugging tools can hook into that. APIDoc itself also enables a feature when it is loaded so you can register things with APIDoc, but only if APIDoc is available. zcml:condition also has another verb, installed, that allows you to load directives only when a certian Python package is available, e.g.: include zcml:condition=installed reportlab package=worldcookery.pdf / meta:provides feature=twidder.defaulttraverser / utility ... zcml:condition=have twiddler.defaulttraverser / This is missing the point. There are an array of inputs, outputs and traversers available. There's a sensible default set registered, but site managers might have different requirements which are likely to include disabling some of the default registrations. Why woudl they have to disable existing ones? Can't they just choose different ones, leaving the default ones sitting there? How should I do things such that they can do that? I'm just wondering whether you really need the disabling feature. I've wanted it. My major beef with the way we are *using* ZCML now is that we expect package authors to provide policy-laden configuration for their packages (sensible defaults) but provide no means for the admin to reuse that configuration selectively; their only realy choice is to *copy* the configuration and edit it. I argued *long* ago (after the first ZC-internal Zope3 sprint, I think) that the 'include' directive should be allowed to be complex, with subelements like 'except' or 'only' to pull in specific directives. Such a practice would require either that we have XPath support available, or else that we come up with a way to mark the directives (e.g., a 'zcml:id' attribute). It would *also* require that we implement the no side-effects during parsing policy (my other favorite dead horse in arguments about ZCML's implementation / usage). Tres. - -- === Tres Seaver +1 202-558-7113 [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 iD8DBQFFEpBV+gerLs4ltQ4RAlldAJ9FwPgZV3NCE16wXiZGwpljrpZfswCeLwU5 PdZXr3WyOcBeEpcAzEe2QEg= =XbgN -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zcml questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Tres Seaver wrote: How should I do things such that they can do that? I'm just wondering whether you really need the disabling feature. I've wanted it. Okay :). My major beef with the way we are *using* ZCML now is that we expect package authors to provide policy-laden configuration for their packages (sensible defaults) but provide no means for the admin to reuse that configuration selectively; their only realy choice is to *copy* the configuration and edit it. True. I argued *long* ago (after the first ZC-internal Zope3 sprint, I think) that the 'include' directive should be allowed to be complex, with subelements like 'except' or 'only' to pull in specific directives. Such a practice would require either that we have XPath support available, or else that we come up with a way to mark the directives (e.g., a 'zcml:id' attribute). Well, we already sort of that this marking with features + zcml:condition. But except and only could be more powerful wrt packages, modules, or even classes and interfaces. It would *also* require that we implement the no side-effects during parsing policy (my other favorite dead horse in arguments about ZCML's implementation / usage). Yup. I think there are very little side effects currently. I can't think of one off of the top of my head, to be honest (but I'm sure there are). We do eager checking of dotted names (during the parse), which makes it impossible to write a directive which synthesisizes the target of a dotted name without side-effects (e.g., the 'five:bridge' directive). If we delayed the check until after parsing was complete, then we could eliminate one source of side effects. Side-effect-free parsing would open a lot of possibilities: ZCML introspector tools, for instance. Tres. - -- === Tres Seaver +1 202-558-7113 [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 iD8DBQFFEpeX+gerLs4ltQ4RApuDAJ9GW+vIzSOzCQ7vj6iUBpmkh5LeFwCcC29l V2u8kqNL/VJKTXOEPc1Ryl0= =gIbE -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zcml questions
On Thursday 21 September 2006 09:15, Tres Seaver wrote: I've wanted it. My major beef with the way we are *using* ZCML now is that we expect package authors to provide policy-laden configuration for their packages (sensible defaults) but provide no means for the admin to reuse that configuration selectively; their only realy choice is to *copy* the configuration and edit it. This has been proposed and approved, but implementation has been delayed due to missing XPath features. http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZCMLEnhancements Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zcml questions
On Sep 21, 2006, at 11:31 AM, Stephan Richter wrote: On Thursday 21 September 2006 09:15, Tres Seaver wrote: I've wanted it. My major beef with the way we are *using* ZCML now is that we expect package authors to provide policy-laden configuration for their packages (sensible defaults) but provide no means for the admin to reuse that configuration selectively; their only realy choice is to *copy* the configuration and edit it. This has been proposed and approved, but implementation has been delayed due to missing XPath features. http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ ZCMLEnhancements I have a feeling that xpath is overkill. It alsoi won't work for actions defined in Python. I'd rather see some sort of identifier system. So, when actions are created, they can have identifiers or properties or something that can be used to filter them out. Any proposal for this, IMO should have a number of well-documented examples. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zcml questions
On Thursday 21 September 2006 11:52, Jim Fulton wrote: I have a feeling that xpath is overkill. I still think that for ZCML XPath is a good approach. People are familiar with it and our designers could just use it presumably. It alsoi won't work for actions defined in Python. I think this is a non-use-case until we have a story (accepted proposal and implementation) for Python actions. Don't anticipate. ;-) I'd rather see some sort of identifier system. So, when actions are created, they can have identifiers or properties or something that can be used to filter them out. The nice thing with XML and XPath is that we already have those identifiers and a standard way to address them. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
