Re: [Zope3-dev] One namespace for ZCML
Jeff Shell wrote: Less directives? Maybe. * Less "does a lot of things for you but offers no easy path to do some of the work yourself?" directives? Yes please. Less "similar to but varying by a couple of small details" directives? (browser:view and browser:page)? Yes please. One namespace for everything? No thanks. Especially if the reason is "I don't like typing those namespaces at the top of the file." Yes, suprisingly to some, +1 to all, and most of the rest of the post for that matter! 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] One namespace for ZCML
On Friday 17 February 2006 07:38, Jim Fulton wrote: > I really think the ArchGenX project has a lot to offer here. Does > anyone know if it is still alive? Yes it is. Jens has started at the Snow Sprint to implement a Zope 3 code generator. Once the new version dubbed AGX is complete they will move to fully support Zope 3 code generation. 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] One namespace for ZCML
Philipp von Weitershausen wrote: Yet again looking for comments, this time at: http://dev.zope.org/Zope3/OneNamespaceForZCML. I assume that this proposal is dead. I haven't read the whole thead, but I think that was the gist. I notice that this proposal no longer is listed on the proposals page. It would be helpful if the proposal status was also updated. Some parting shots: - We should not be trying to reinvent ZCML. It's XML. If you don't like that, get over it. - We do need a better high-level configuration system for doing the sorts of things that we use ZConfig for, and maybe some things we currently use ZConfig for. But that's a different discussion that I'll get back to soon. - We need to find the riht balence between ZCML and Python. There are many places where we did too much in ZCML. Everybody makes mistakes. That's how we learn. :) - As a general rule, things should be defined in Python (or perhaps other definition languages) and *registered* in ZCML. Certainly, "core" ZCML directives should be about reigistration/configuration not definition. An example of a non-python definition language is something like XMI, which might provide an alternative way to define schema via UML. - BTW, I wouldn't object to having one "core" namespace. - We need to recognize the concerns of different kinds of users. There will be users for which high-level directives will be beneficial, even when these high-level directives define as well as configure. I think these high-level directives will often be project specific. Then again, a better alternative might be to use high-level definition language like XMI. I really think the ArchGenX project has a lot to offer here. Does anyone know if it is still alive? Please resist the temptation to respond to this post and drag out this discussion further. 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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
On Thu, Feb 16, 2006 at 12:31:46PM -0500, Paul Winkler wrote: > On Thu, Feb 16, 2006 at 01:19:38AM -0700, Jeff Shell wrote: > > Am I the only person who uses apidoc to look up what can be done with > > ZCML? > > I dunno if it's just me, but http://localhost:8080/++apidoc++ > is 404 on a fresh 3.2 instance. It was just me, cancel that :-) -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
On Thu, Feb 16, 2006 at 01:19:38AM -0700, Jeff Shell wrote: > Am I the only person who uses apidoc to look up what can be done with > ZCML? I dunno if it's just me, but http://localhost:8080/++apidoc++ is 404 on a fresh 3.2 instance. Aside from that, I noticed that the "help" popup in the ZMI contained a link to http://dev.zope.org/Zope3/FAQ which redirects to http://www.zope.org/DevHome/Wikis/DevSite/Projects/ComponentArchitecture/FAQ which was really really horribly out of date. I just very quickly updated a bunch of things, some of them are still probably wrong, I didn't look at everything. It's still in need of attention from some more knowledgable folks... even five minutes could make a difference. -PW -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
Jeff Shell wrote: > Am I the only person who uses apidoc to look up what can be done with > ZCML? Because honestly, finding out what directives are available and > getting decent documentation about ZCML directives is the easiest > thing in Zope 3. Understanding what's going on or what the real > meaning of a particular value in combination with others might be - > that's a different story. But finding out what namespaces are > available and what the directives are has never been a problem. And I > spend most of my apidoc time (when looking at ZCML) with the 'browser' > and 'zope' nodes expanded. I rarely need the others ones. > > Less directives? Maybe. * > Less "does a lot of things for you but offers no easy path to do some > of the work yourself?" directives? Yes please. > Less "similar to but varying by a couple of small details" directives? > (browser:view and browser:page)? Yes please. I find the subtle difference between browser:view and browser:page disturbing There are also more things about them that I find very annoying. But that's not the topic here... (see below) > One namespace for everything? No thanks. Yes, point is taken, the proposal has been retracted. > Especially if the reason is > "I don't like typing those namespaces at the top of the file." Was never my point... The following discussion really belongs into the other thread discussing my "Reducing the amount of ZCML directives" proposal. I'll answer your points now, but if you have detailed comments on just that proposal, then let's use the other thread. This thread should be dead because I took everyone's point and retracted the proposal (for now). > * I don't mind directives that are easy to read by eye. Lumping > everything into and is not going to make things > easier to read. I like . I like . I just > wouldn't mind the documentation saying is shorthand > for ..., and can be done in pure Python and one line of ZCML by It's not all about reading things. It's also about making a sense out of them. If we'd just be looking at ZCML, then yes, nice and descriptive directive names would be best. Looking at the bigger picture, we want people to understand what they're doing. At least I myself prefer to understand what I'm doing. By the way, it's not only myself that I have in mind but also the one I'm teaching about Zope. More consistency and less magic in ZCML would've made my life a lot easier when writing the 1st edition of the book and giving trainings to people... > I'd also like to see documentation about when custom classes are > created and why, and what to do if you don't want the ZCML to generate > things for you.. It may have good reasons for generating things, I'd > just like to know why. Because god knows, that's the code that I have > the hardest time reading. (_discriminator this, handler_ that..). There are no reasons for generating things. Cryptical things, should they occur, can be tucked away in sensible base classes (the examples you bring don't make any sense to me, but I give you as much that there *are* some cryptical things). The idea of making ZCML directives do less is explicitness, not unnecessary verbosity. Creating stuff on the fly border magic. In case of browser:page/browser:view it's much farther than just the border. FWIW, I brainstormed on this in http://www.z3lab.org/sections/blogs/philipp-weitershausen/2005_12_14_zcml-needs-to-do-less. I'm currently evaluating some of those ideas, ammending them to what perhaps could become a proposal... Not sure yet. Input is definitely welcome. In any case I don't think the examples I'm giving are overly cryptic. Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
On 2/15/06, Chris Withers <[EMAIL PROTECTED]> wrote: > Stephan Richter wrote: > > I do not think namespace declarations are dead chickens. For me declaring a > > namespace in ZCML is the same as importing a package or module in Python. > > You > > would not want all functions and classes in Python live in one namespace, > > would you? > > The more namespaces, the more needs to be learned, the more confusion. > ZCML is not python, comparing the two isn't right. > > I'm all for simpler and simpler zcml... A single namespace with more options is not a better solution. THAT means more to learn, because now I have more options to sift through. When the units of work are segmented out to appropriate subsystems (and kept reasonable and free of magic), namespaces in ZCML are and could still be a good thing. Am I the only person who uses apidoc to look up what can be done with ZCML? Because honestly, finding out what directives are available and getting decent documentation about ZCML directives is the easiest thing in Zope 3. Understanding what's going on or what the real meaning of a particular value in combination with others might be - that's a different story. But finding out what namespaces are available and what the directives are has never been a problem. And I spend most of my apidoc time (when looking at ZCML) with the 'browser' and 'zope' nodes expanded. I rarely need the others ones. Less directives? Maybe. * Less "does a lot of things for you but offers no easy path to do some of the work yourself?" directives? Yes please. Less "similar to but varying by a couple of small details" directives? (browser:view and browser:page)? Yes please. One namespace for everything? No thanks. Especially if the reason is "I don't like typing those namespaces at the top of the file." Modularity is a good thing. Trust me! We don't need 100 namespaces, we don't need 50, but we can't lump it all in one. I still think that's the wrong fight to fight right now. * I don't mind directives that are easy to read by eye. Lumping everything into and is not going to make things easier to read. I like . I like . I just wouldn't mind the documentation saying is shorthand for ..., and can be done in pure Python and one line of ZCML by I'd also like to see documentation about when custom classes are created and why, and what to do if you don't want the ZCML to generate things for you.. It may have good reasons for generating things, I'd just like to know why. Because god knows, that's the code that I have the hardest time reading. (_discriminator this, handler_ that..). ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
Stephan Richter wrote: That said, there might still be a small percentage of cases where custom directives are a valid tool. I can accept their being on the same namespace as others. In fact, I would like it to be that way, reducing the amount of dead chickens (namespace declarations). I do not think namespace declarations are dead chickens. For me declaring a namespace in ZCML is the same as importing a package or module in Python. You would not want all functions and classes in Python live in one namespace, would you? The more namespaces, the more needs to be learned, the more confusion. ZCML is not python, comparing the two isn't right. I'm all for simpler and simpler zcml... 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] One namespace for ZCML
Philipp von Weitershausen wrote: directives. I realize "somewhat" is fuzzy. Let me just say that I think ZCML has failed when Plone will have its own ZCML directives... There's a mailing list post from ages ago about going off and humping the leg of the next great thing. Plohn _will_ grow its own directives, simply because it can... you wait ;-) cheers, Chris - feeling cynical tonight, sorry... -- 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] One namespace for ZCML
Philipp von Weitershausen wrote: Martijn Faassen wrote: [snip] * a way to register an XSLT renderer. * registering XML importers and exporters. These two immediately triggered "adapter" in my mind :). XSLT renderer may be a view, that's how we use them now. I think it's a candidate for a fairly easy transition to Zope 3 style concepts, in fact. There are subtleties with XML importers that don't really map to adapters directly, at least not in a simple way - you want to register different importers for certain XML tags. [snip] It's important, though, that we do try to find a good match between the Zope 3 ways of doing things and the historical baggage. In Zope 3 we have developed a nice way of looking at things and fit them into very simple concepts. It should be preserved. Sure, but I want my silva namespace so I don't pollute the Zope 3 space. :) Same reason I'm happy with the five namespace. Btw, I find it a bit scary that you're trying to replace an install method with a lot of ZCML directives. I'm not sure I would welcome a procedure expressed through configuration. It seems like some of these problems are better tucked away using a deployment framework like GenericSetup. But then again, I'm not really familiar with Silva and that install.py thing. Silva's 'install.py' does a lot of stuff that really should be declaration, not procedure. Registering metadata sets for content types, registering views, etc, etc. Then extensions to Silva also do the same thing. GenericSetup would make sense for some of it, but I suspect fairly little, except of course that right now lots of Silva's configuration, often unnecessarily, ends up in the ZODB. [snip] I put in a smiley, but I'm serious about the underlying problem of exposing a lot of long dotted names into Python modules into ZCML. No worries, I got the tone of the message. However, to every satire there's a true core message, as you're pointing out yourself. I too am concerned, but I also think that because dotted names actually have a meaning, they might be handier in the end than cryptic short forms. And then there's also the point of intrinsic information of a component that we're currently putting into ZCML but are starting to put into Python. I has already reduced the amount of dotted names necessary. Yes, I saw that point of yours in another thread replying to me there, and I think that's a very good point. Anyway, in my attitude to ZCML I'm for piecemeal evolution right now - I don't think ruthless refactoring is really necessary, but we can get quite ruthless on certain directives or attributes of certain directives. I wonder whether we can do things to make this look simpler. If the dotted names were not hiding in attributes but in element content, we could come up with some kind of XML vocabulary for them, even. :) At least it would give you the possibility to define and use XML entities for them :). Seriously, though, I wouldn't be sure of my vote for a system like that. As said, dotted names have a meaningful background (Python import paths). Abbreviations most likely don't. I rather build something that makes sense than one that relies on too many naming conventions... Agreed; this needs to be thought through carefully. We don't want to replace dotted names with a lot of shorter stuff you need to memorize anyway, either. It needs to be somehow predictable, and perhaps dotted names are the best we can do, if we can at least get rid of some of them and move it into Python. It's just an interesting area to think about. I just think having to declare 3 to 5 different namespaces on the top of the file of which some have no apparent meaning or distinction seems like clutter to me. Some indeed have no apparent meaning and distinction; I think zcml:condition could be safely folded into Zope's namespace. When I see apidoc or wfmc I can identify what is involved, though - possibly they can still be eliminated but they definitely have meaning to me. In the documentlibrary, so far we've only used two namespaces, zope and browser. In schooltool, more namespace happen: apidoc, wfmc, i18n and zcml. I think eliminating the 'zcml' namespace would get us down to 2 or less declarations for most .zcml files. I think the 'zcml' namespace should be separate from the 'zope' one because 'zcml' is meta-ish whereas 'zope' is about actual and factual directives. I would rather see 'meta' directives folded into 'zcml' (like I propose in the proposal). zope:include and friends are meta-ish too though. Moving those into a separate namespace would suddenly grow the amount of namespaces necessary. Perhaps folding the meta namespace (+ zcml) into zope is actually something we can explore. The meta namespace should be a fairly solid XML vocabulary after all. Note that I absolutely see the necessity for namespace declarations. For example, I would like to see ZPT require the declaration of TAL, METAL and I18N n
Re: [Zope3-dev] One namespace for ZCML
Martijn Faassen wrote: >> I would really like to hear what kind of directives you imagine for >> Silva here (and what you mean by "new ways to configure components"). > > > The following are candidates, though note I haven't thought this through > deeply for any of them: > > * a way to register a Silva content object. > > * a way to register a content object version. > > * a way to register a Silva metadata set. > > * registering directory views (could go into CMF, though Silva is not > using it directly now) ... > * registering a silva service into the Silva root > > * configuring which objects can be addable. > > * setting up zope 2 permission/role mapping in Silva root. > > * setting up the zope 2 catalog indexes. I guess most of these fall under the "registering something that isn't a utility or adapter" category which is fine. Though I wouldn't be surprised some of those registrations could be boiled down to simpler, Zope-3-style things like menu items or utilities. Oh wait, you mention that yourself :). > * a way to register an XSLT renderer. > > * registering XML importers and exporters. These two immediately triggered "adapter" in my mind :). > I think some, or even all, of these can probably turn *eventually* into > Zope 3-style approaches directly - probably services will become some > sort of local utilities, and directory views will become Zope 3 view, > XSLT another, and the importers/exporters will become some sort of > adapters, addables menus. > > The emphasis is on eventually, as I certainly expect it to be useful in > a transition phase to clean out Silva's current grotty install.py and > replace it with ZCML that doesn't require significant refactorings of > Silva yet. Replacing this stuff with native Zope 3 components is > generally a major task. I agree on the eventuality. It's important, though, that we do try to find a good match between the Zope 3 ways of doing things and the historical baggage. In Zope 3 we have developed a nice way of looking at things and fit them into very simple concepts. It should be preserved. Btw, I find it a bit scary that you're trying to replace an install method with a lot of ZCML directives. I'm not sure I would welcome a procedure expressed through configuration. It seems like some of these problems are better tucked away using a deployment framework like GenericSetup. But then again, I'm not really familiar with Silva and that install.py thing. >>> Sometimes a new, short directive is a lot easier to >>> remember than to remember long.dotted.names.pointing.to.places and 3 >>> directives. Having to remember (or worse, look up) long dotted names is >>> extremely common in ZCML and I consider it at least as big a problem as >>> having to learn directives. >> >> >> I agree. Many of these long dotted names belong into Python, though. >> >> >>> Let's use abstraction and naming things where it makes sense. >>> >>> Heh, perhaps we need to go the other way and add a namespace directive >>> for long dotted names instead. :) >> >> >> -1. > > > I put in a smiley, but I'm serious about the underlying problem of > exposing a lot of long dotted names into Python modules into ZCML. No worries, I got the tone of the message. However, to every satire there's a true core message, as you're pointing out yourself. I too am concerned, but I also think that because dotted names actually have a meaning, they might be handier in the end than cryptic short forms. And then there's also the point of intrinsic information of a component that we're currently putting into ZCML but are starting to put into Python. I has already reduced the amount of dotted names necessary. > I wonder whether we can do things to make this look simpler. If the > dotted names were not hiding in attributes but in element content, we > could come up with some kind of XML vocabulary for them, even. :) At least it would give you the possibility to define and use XML entities for them :). Seriously, though, I wouldn't be sure of my vote for a system like that. As said, dotted names have a meaningful background (Python import paths). Abbreviations most likely don't. I rather build something that makes sense than one that relies on too many naming conventions... That said, there might still be a small percentage of cases where custom directives are a valid tool. I can accept their being on the same namespace as others. In fact, I would like it to be that way, reducing the amount of dead chickens (namespace declarations). >>> >>> >>> Namespace declarations are not dead chickens. They're things that the >>> XML language requires. Indentation and colons are not dead chickens in >>> Python either. *particular* namespace declarations may be unnecessary - >>> but not dead chickens, just perhaps the wrong solution. >> >> >> Yeah, sorry, bad wording. I just think having to declare 3 to 5 different >> namespaces on the top of the file of which some have no appa
Re: [Zope3-dev] One namespace for ZCML
Philipp von Weitershausen wrote: Martijn Faassen wrote: [snip] Moreover, sometimes a package introduces new ways to configure components. Five does so, for instance, and Silva will too eventually. I would really like to hear what kind of directives you imagine for Silva here (and what you mean by "new ways to configure components"). The following are candidates, though note I haven't thought this through deeply for any of them: * a way to register a Silva content object. * a way to register a content object version. * a way to register a Silva metadata set. * registering directory views (could go into CMF, though Silva is not using it directly now) * a way to register an XSLT renderer. * registering XML importers and exporters. * registering a silva service into the Silva root * configuring which objects can be addable. * setting up zope 2 permission/role mapping in Silva root. * setting up the zope 2 catalog indexes. I think some, or even all, of these can probably turn *eventually* into Zope 3-style approaches directly - probably services will become some sort of local utilities, and directory views will become Zope 3 view, XSLT another, and the importers/exporters will become some sort of adapters, addables menus. The emphasis is on eventually, as I certainly expect it to be useful in a transition phase to clean out Silva's current grotty install.py and replace it with ZCML that doesn't require significant refactorings of Silva yet. Replacing this stuff with native Zope 3 components is generally a major task. I expect a very similar story applies to CMF, and again to CMF-based systems like Plone. Sometimes a new, short directive is a lot easier to remember than to remember long.dotted.names.pointing.to.places and 3 directives. Having to remember (or worse, look up) long dotted names is extremely common in ZCML and I consider it at least as big a problem as having to learn directives. I agree. Many of these long dotted names belong into Python, though. Let's use abstraction and naming things where it makes sense. Heh, perhaps we need to go the other way and add a namespace directive for long dotted names instead. :) -1. I put in a smiley, but I'm serious about the underlying problem of exposing a lot of long dotted names into Python modules into ZCML. I wonder whether we can do things to make this look simpler. If the dotted names were not hiding in attributes but in element content, we could come up with some kind of XML vocabulary for them, even. :) That said, there might still be a small percentage of cases where custom directives are a valid tool. I can accept their being on the same namespace as others. In fact, I would like it to be that way, reducing the amount of dead chickens (namespace declarations). Namespace declarations are not dead chickens. They're things that the XML language requires. Indentation and colons are not dead chickens in Python either. *particular* namespace declarations may be unnecessary - but not dead chickens, just perhaps the wrong solution. Yeah, sorry, bad wording. I just think having to declare 3 to 5 different namespaces on the top of the file of which some have no apparent meaning or distinction seems like clutter to me. Some indeed have no apparent meaning and distinction; I think zcml:condition could be safely folded into Zope's namespace. When I see apidoc or wfmc I can identify what is involved, though - possibly they can still be eliminated but they definitely have meaning to me. In the documentlibrary, so far we've only used two namespaces, zope and browser. In schooltool, more namespace happen: apidoc, wfmc, i18n and zcml. I think eliminating the 'zcml' namespace would get us down to 2 or less declarations for most .zcml files. Note that I absolutely see the necessity for namespace declarations. For example, I would like to see ZPT require the declaration of TAL, METAL and I18N namespaces. Note that there the entire namespace story is different. There they are used for what I think namespaces are intended, separating several XML models (e.g. the HTML model from the additional TAL/METAL/I18N model). I think Zope 3 extensions extend the Zope 3 XML model. They're less different than combining XHTML with TAL, but I still see a core vocabulary with potentially arbitrary extensions. 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] One namespace for ZCML
Jeff Shell wrote: > I still HATE magical ZCML. But I still think ZCML is a good thing and > should be modularized. Simplified - yes. Modular (namespaces) - yes. That seems to be the core message of most of the feedback I got. I'll be happy to hear more detailed suggestions on what should be simplified and/or modularized. Of course, I also have a few of my own, some of them are already listed at the bottom of the other proposal... Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
On 2/13/06, Stephan Richter <[EMAIL PROTECTED]> wrote: > On Monday 13 February 2006 07:57, Philipp von Weitershausen wrote: > > Yet again looking for comments, this time at: > > http://dev.zope.org/Zope3/OneNamespaceForZCML. > > -1 > > Here some comments: > > - You do not argue how the decision-making process is "highly inconsistent". > > - I do not understand what's so bad about coming up with your 3rd-party ZCML > directives. They are extremely easy to write and use. I think that 3rd-party > ZCML directives are not a bad thing. And yes, I would like to keep those in a > separate namespace. I am also -1. But I take issue with your second statement. ZCML directives are the hardest and scariest code in Zope 3 to understand. It was easier to figure out what was going on with multi-adapter lookup than to figure out how menuItems work! (I lost a day trying to figure out if I could just put a javascript condition on a menu item before coming up with a glorious trick). I still HATE magical ZCML. But I still think ZCML is a good thing and should be modularized. Simplified - yes. Modular (namespaces) - yes. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
OK, after following the diskussion I'm now -1. Lets first go through Phillips other ZCML simplification, then look at what we can do for browser:*, and then see if what's left should have several namespaces or not. I think that people who can't be bohered to copy/paste a set of names-space definitions first in the file will not bother to copy/paste one name-space definition, and hence I think having just one namespace is not gonna make anybody happy, unless all statements neatly fit there. On the other hand, namespaces with just a couple of statements are most likely some kind of chicken (although maybe not dead). So lets see what we end up with when we have pruned the statements a bit. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
Martijn Faassen wrote: > I want to evolve ZCML as it is right now, this might mean removing > directives, changing directives, consolidating directives, adding > directives, removing some namespaces, consolidating some namespaces, > even adding some namespaces. Fair enough. I'm already looking forward to your suggestions! > I think we are at a point in evolution where we want to focus on removal > and consolidation. In general, ZCML is ready for a careful rethink. I > agree we should do such a rethink focused on simplification. > > That doesn't mean that I think we should remove the ability to add > directives I never said I wanted to limit ZCML's extensibility mechanism. > or namespaces; I think that is removal gone too far. I think > there are legitimate use cases for both abilities. > > I think that this position is quite consistent. :) Sure, it's consistent. It also lacks a bit meat :). Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
Martijn Faassen wrote: > I don't see the problem with learning new ZCML directives when I'm > learning a new package. I can see why you'd like to reduce the > occurence, and I think sometimes configuring things in ZCML is actually > doing it in the wrong place, as information needs to be persistent > sometimes. I agree. Having to remember how to work with a new ZCML directive *is* a burden, though. Given that we're all Python programmers, I would say that it's more of a burden than having to remember a Python API. > Moreover, sometimes a package introduces new ways to configure > components. Five does so, for instance, and Silva will too eventually. I would really like to hear what kind of directives you imagine for Silva here (and what you mean by "new ways to configure components"). > Sometimes a new, short directive is a lot easier to > remember than to remember long.dotted.names.pointing.to.places and 3 > directives. Having to remember (or worse, look up) long dotted names is > extremely common in ZCML and I consider it at least as big a problem as > having to learn directives. I agree. Many of these long dotted names belong into Python, though. > Let's use abstraction and naming things where it makes sense. > > Heh, perhaps we need to go the other way and add a namespace directive > for long dotted names instead. :) -1. > > That said, there might still be a small percentage of cases where custom > > directives are a valid tool. I can accept their being on the same > > namespace as > > others. In fact, I would like it to be that way, reducing the amount of > > dead chickens (namespace declarations). > > Namespace declarations are not dead chickens. They're things that the > XML language requires. Indentation and colons are not dead chickens in > Python either. *particular* namespace declarations may be unnecessary - > but not dead chickens, just perhaps the wrong solution. Yeah, sorry, bad wording. I just think having to declare 3 to 5 different namespaces on the top of the file of which some have no apparent meaning or distinction seems like clutter to me. Note that I absolutely see the necessity for namespace declarations. For example, I would like to see ZPT require the declaration of TAL, METAL and I18N namespaces. Note that there the entire namespace story is different. There they are used for what I think namespaces are intended, separating several XML models (e.g. the HTML model from the additional TAL/METAL/I18N model). Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
Martijn Faassen wrote: > > No. But I don't think that it'll be much of a problem. I expect that not a > > lot of 3rd party packages will need their own set of ZCML directives. > > Currently I know of five and union.cms doing it. I'm certainly > considering doing so for Silva. Then there's the example of many > packages in the Zope 3 core which are actually quite independent from > the core itself, such as the email package, and may in the future become > Zope extensions. Here's what I think are valid reasons for having directives beyond the ones I call "elementary": * You need to register something that isn't a utility or adapter. The security policy comes in bind, but also a TALES namespace adapter or even global principals. CMF or Zope 2-specific directives for registering meta/portal types are also covered by this. * You need to register an elementary component but with added policy information that doesn't belong in code. This basically includes: - security information (that's why we have view, browser:page, etc.) in addition to the plain adapter directive, it also justifies the content/class directive. - configuration information for the component (e.g. SMTP host for the mailer utility, locales directory for the gettext message catalogs, text file for the help topic) * You need additional ways to define policy (e.g. granting permissions on roles, etc.) I think we can fit many existing directives minus the ones I'd like to get rid of in the other proposal into these three categories. That means I'm not questioning many more directives than the ones I'm talking about (incl. the ones at the bottom of the proposals). However, I *am* questioning the need for a lot of custom directives in 3rd party packages. Given the usecases for ZCML directives above, I don't see Silva or Plone themself bringing in new directives, but I could imagine a Silva-specific security policy would have some. Or a Plone-specific Cache manager. That's perfectly ok with me, they need to define policy in addition to just being registered. Just note that I'm explicitly not addressing automation as a use case for custom ZCML directives. I believe automation is best done in Python. If you're trying to invent a new ZCML directive that does something else to an adapter/view/utility before registering it (e.g. putting an interface on it, adding attributes, wrapping it in a factory etc.), then that should be done in Python. zope.formlib is a good example of how browser:page is enough for registering a form as it isn't ZCML's concern *what* kind of page we're registering. All that is in Python. > I'd say adding a namespace is a common method for abstracting > application specific component configuration tasks. Not sure what you mean by these last five words :). I agree that namespaces are a good idea to avoid name clashes. I like how we use dotted names for permissions, factory names, etc. Just note that there seems to be somewhat of a consensus on how to use those (invent your own dotted name-prefix for your own package). Only *that* makes the namespace convention actually avoid name clashes. In ZCML we don't seem to have an understanding of what goes into which namespace. I'm trying to figure it out. Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
Martijn Faassen wrote: > Prefixing 'browser' directives in the tag names to me is a big warning > bell that you really do want to use different namespaces. Another > example of the namespace mechanism working is that some people are using > it in their projects, adding namespaces specific to their project. It'd > feel ugly to me if I had to insert my own configuration directives into > Zope's. Perhaps it is ugly, yet other well-known and widely used systems let extensions create new configuration directives w/o a need for a namespace. The Apache HTTP server is an example, ZConfig another one. It seems from an aesthetic point of view, many people would like to use namespaces. It's interesting that I got +1 comments back then and not today. Perhaps the reality of the proposal looked different than what people expected. Then it's still a good thing having discussed this matter. Especially because I'm still not convinced that we really understand what ZCML namespaces mean to us (see below). > Finally, a general use of programming should be to use the language's > namespace directive instead of prefixes, if the language does offer an > effective namespace directive. > > So, please don't try to fix this now. Work on reducing the complexity of > existing directives first, and work on deprecating directives. Then > reconsider this one. That is a valid concern. I too get the feeling that it might be a bit too early for this. I regard(ed) the two proposals I brought in yesterday as orthogonal to each other, but perhaps they share more causality than I would like them to. > Perhaps after this other step, matters will be clearer. I suspect quite > a few of the directives that can go away are in the 'small' namespaces, > such as mail. We may also want to move some directives to other > namespaces. If all directives disappear from a namespace, so can the > namespace. The potential for win can be much larger while the potential > for breakage is much smaller, as we can do this step by step. I agree. As we do that, we should also try to figure out when and how we decide what goes into its own namespace and what doesn't. Currently ZCML namespaces are used to: * Differentiate between different view types (generic vs. browser vs. xmlrpc) * Mark the domain of a certain registration (i18n, mail, rdb, help) * Associate directives with a certain, perhaps optional package (apidoc, other 3rd party packages) Why does apidoc have its own namespace and, say, zope.app.securitypolicy doesn't? Or why did zope.viewlet not put its directives into the 'viewlet' namespace but into the 'browser' namespace? All that seems arbitrary to me. Just as the fact that I'm "supposed" to put my frobnatz directive into the plone namespace even if a frobnatz is actually a browser thing. > I really think that the discussion on namespaces is so common not > because it's so important, but because it's an easy thing to comment on > and talk about. People are less likely to have huge discussions about > larger but harder to understand issues. Perhaps. But it also seems like they're talking about it because it bugs them a lot. Tres seems to think that we shouldn't worry about those "trolls". I'm inclined to think that if people have issues with ZCML and welcome simplifications, we should consider coming up with some. So far I'm the only one who has made constructive suggestions for doing so beyond Jim's adapts() hook (I won't count suggestions that seek to replace ZCML with ZConfig, YAML, etc.). Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
Philipp von Weitershausen wrote:
Stephan Richter wrote:
As we have learned that we can reduce nearly all component tasks to
adapters and utilities, many tasks revolving around registration and
configuration of policy also only involve adapters and utilities. By using
those "elementary" directives we can stimulate the learning process for
developers ("there should only be one way of doing things"). Yes, you might
have to use two or three directives instead of just one new one, but you'll
know what you're doing... And you'll remember it in 2 months. I think
that's more valuable than saving a couple of lines today.
I think this is the wrong thread. :-) We are discussing the one namespace
here. If I would be against replacing one special directive with a couple
fundamental directives, I would have voted -1 on the other proposal, which I
did not.
So, you agree that the number of ZCML directives should not grow too
much, yet you say that you want to keep people adding new directives.
That doesn't add up for me.
I agree with Stephan, so I'll point out why I don't think I'm inconsistent:
I want to evolve ZCML as it is right now, this might mean removing
directives, changing directives, consolidating directives, adding
directives, removing some namespaces, consolidating some namespaces,
even adding some namespaces.
I think we are at a point in evolution where we want to focus on removal
and consolidation. In general, ZCML is ready for a careful rethink. I
agree we should do such a rethink focused on simplification.
That doesn't mean that I think we should remove the ability to add
directives or namespaces; I think that is removal gone too far. I think
there are legitimate use cases for both abilities.
I think that this position is quite consistent. :)
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] One namespace for ZCML
Philipp von Weitershausen wrote:
Stephan Richter wrote:
- You do not argue how the decision-making process is "highly inconsistent".
Fair enough. I will update the proposal later. Supper first :).
- I do not understand what's so bad about coming up with your 3rd-party ZCML
directives. They are extremely easy to write and use. I think that 3rd-party
ZCML directives are not a bad thing. And yes, I would like to keep those in
a separate namespace.
Sure, it's easy to write ZCML directives. It's also possible to write ZCML
directives that are easy to use, but just as well to write ones that are hard
to use. So your generalization above is a bit too, well, general :).
The problem is uncontrolled ZCML directive proliferation. It's "bad" enough
that you have to familiarize yourself with a new API when dealing with a 3rd
party Zope package. But having to learn a new set of ZCML directives?!? I
think many people would be skeptical. Me included.
I don't see the problem with learning new ZCML directives when I'm
learning a new package. I can see why you'd like to reduce the
occurence, and I think sometimes configuring things in ZCML is actually
doing it in the wrong place, as information needs to be persistent
sometimes. Learning a new ZCML directive is the least of my concern when
learning how to use a new package, however.
Moreover, sometimes a package introduces new ways to configure
components. Five does so, for instance, and Silva will too eventually.
As we have learned that we can reduce nearly all component tasks to adapters
and utilities, many tasks revolving around registration and configuration of
policy also only involve adapters and utilities. By using those "elementary"
directives we can stimulate the learning process for developers ("there should
only be one way of doing things"). Yes, you might have to use two or three
directives instead of just one new one, but you'll know what you're doing...
And you'll remember it in 2 months. I think that's more valuable than saving a
couple of lines today.
I think I disagree with this one too; the situation is at least rather
more subtle. Sometimes a new, short directive is a lot easier to
remember than to remember long.dotted.names.pointing.to.places and 3
directives. Having to remember (or worse, look up) long dotted names is
extremely common in ZCML and I consider it at least as big a problem as
having to learn directives. Let's use abstraction and naming things
where it makes sense.
Heh, perhaps we need to go the other way and add a namespace directive
for long dotted names instead. :)
That said, there might still be a small percentage of cases where custom
directives are a valid tool. I can accept their being on the same namespace as
others. In fact, I would like it to be that way, reducing the amount of dead
chickens (namespace declarations).
Namespace declarations are not dead chickens. They're things that the
XML language requires. Indentation and colons are not dead chickens in
Python either. *particular* namespace declarations may be unnecessary -
but not dead chickens, just perhaps the wrong solution.
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] One namespace for ZCML
Philipp von Weitershausen wrote: Lennart Regebro wrote: On 2/13/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Yet again looking for comments, this time at: http://dev.zope.org/Zope3/OneNamespaceForZCML. What happens if you want to add your own statements? Should you still do that in your own namespace? No. But I don't think that it'll be much of a problem. I expect that not a lot of 3rd party packages will need their own set of ZCML directives. Currently I know of five and union.cms doing it. I'm certainly considering doing so for Silva. Then there's the example of many packages in the Zope 3 core which are actually quite independent from the core itself, such as the email package, and may in the future become Zope extensions. I'd say adding a namespace is a common method for abstracting application specific component configuration tasks. I also don't see what's bad about it and why we'd like to discourage it. 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] One namespace for ZCML
Philipp von Weitershausen wrote: Yet again looking for comments, this time at: http://dev.zope.org/Zope3/OneNamespaceForZCML. -1. Prefixing 'browser' directives in the tag names to me is a big warning bell that you really do want to use different namespaces. Another example of the namespace mechanism working is that some people are using it in their projects, adding namespaces specific to their project. It'd feel ugly to me if I had to insert my own configuration directives into Zope's. Finally, a general use of programming should be to use the language's namespace directive instead of prefixes, if the language does offer an effective namespace directive. So, please don't try to fix this now. Work on reducing the complexity of existing directives first, and work on deprecating directives. Then reconsider this one. Perhaps after this other step, matters will be clearer. I suspect quite a few of the directives that can go away are in the 'small' namespaces, such as mail. We may also want to move some directives to other namespaces. If all directives disappear from a namespace, so can the namespace. The potential for win can be much larger while the potential for breakage is much smaller, as we can do this step by step. I really think that the discussion on namespaces is so common not because it's so important, but because it's an easy thing to comment on and talk about. People are less likely to have huge discussions about larger but harder to understand issues. In the spirit of that, I will next talk about your proposal to remove specific ZCML directives. 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] One namespace for ZCML
Stephan Richter wrote:
>>As we have learned that we can reduce nearly all component tasks to
>>adapters and utilities, many tasks revolving around registration and
>>configuration of policy also only involve adapters and utilities. By using
>>those "elementary" directives we can stimulate the learning process for
>>developers ("there should only be one way of doing things"). Yes, you might
>>have to use two or three directives instead of just one new one, but you'll
>>know what you're doing... And you'll remember it in 2 months. I think
>>that's more valuable than saving a couple of lines today.
>
>
> I think this is the wrong thread. :-) We are discussing the one namespace
> here. If I would be against replacing one special directive with a couple
> fundamental directives, I would have voted -1 on the other proposal, which I
> did not.
So, you agree that the number of ZCML directives should not grow too
much, yet you say that you want to keep people adding new directives.
That doesn't add up for me.
>>That said, there might still be a small percentage of cases where custom
>>directives are a valid tool. I can accept their being on the same namespace
>>as others. In fact, I would like it to be that way, reducing the amount of
>>dead chickens (namespace declarations).
>
> I do not think namespace declarations are dead chickens.
Per se, they aren't dead chicken for me either.
> For me declaring a
> namespace in ZCML is the same as importing a package or module in Python.
That's not quite what it is for me. Rather than a package-afiliation,
namespaces currently seem to indicate usage (browser:view vs.
xmlrpc:view). To use namespaces for this seems arbitrary. This is also
along similar lines of the "The distinction which goes into what
namespace is highly inconsistent" problem. Why would security-related
stuff not have a 'security' namespace, but 'browser' stuff does?
Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
On Monday 13 February 2006 08:36, Philipp von Weitershausen wrote:
> As we have learned that we can reduce nearly all component tasks to
> adapters and utilities, many tasks revolving around registration and
> configuration of policy also only involve adapters and utilities. By using
> those "elementary" directives we can stimulate the learning process for
> developers ("there should only be one way of doing things"). Yes, you might
> have to use two or three directives instead of just one new one, but you'll
> know what you're doing... And you'll remember it in 2 months. I think
> that's more valuable than saving a couple of lines today.
I think this is the wrong thread. :-) We are discussing the one namespace
here. If I would be against replacing one special directive with a couple
fundamental directives, I would have voted -1 on the other proposal, which I
did not.
> That said, there might still be a small percentage of cases where custom
> directives are a valid tool. I can accept their being on the same namespace
> as others. In fact, I would like it to be that way, reducing the amount of
> dead chickens (namespace declarations).
I do not think namespace declarations are dead chickens. For me declaring a
namespace in ZCML is the same as importing a package or module in Python. You
would not want all functions and classes in Python live in one namespace,
would you?
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] One namespace for ZCML
Stephan Richter wrote:
> - You do not argue how the decision-making process is "highly inconsistent".
Fair enough. I will update the proposal later. Supper first :).
> - I do not understand what's so bad about coming up with your 3rd-party ZCML
> directives. They are extremely easy to write and use. I think that 3rd-party
> ZCML directives are not a bad thing. And yes, I would like to keep those in
> a separate namespace.
Sure, it's easy to write ZCML directives. It's also possible to write ZCML
directives that are easy to use, but just as well to write ones that are hard
to use. So your generalization above is a bit too, well, general :).
The problem is uncontrolled ZCML directive proliferation. It's "bad" enough
that you have to familiarize yourself with a new API when dealing with a 3rd
party Zope package. But having to learn a new set of ZCML directives?!? I
think many people would be skeptical. Me included.
As we have learned that we can reduce nearly all component tasks to adapters
and utilities, many tasks revolving around registration and configuration of
policy also only involve adapters and utilities. By using those "elementary"
directives we can stimulate the learning process for developers ("there should
only be one way of doing things"). Yes, you might have to use two or three
directives instead of just one new one, but you'll know what you're doing...
And you'll remember it in 2 months. I think that's more valuable than saving a
couple of lines today.
That said, there might still be a small percentage of cases where custom
directives are a valid tool. I can accept their being on the same namespace as
others. In fact, I would like it to be that way, reducing the amount of dead
chickens (namespace declarations).
Philipp
This message was sent using IMP, the Internet Messaging Program.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
On 2/13/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > By choosing decent names for the few directives that will be necessary. I > know, > it sounds lame, but even *with* namespace you'd need decent names. Or does > anything prevent me in my own package to register a ZCML directive called > browser:viewlet? Nope. So, it doesn't make much of a difference with or w/o > namespaces. Right, but at least then you can argue that you have done somthing evidently wrong. :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.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] One namespace for ZCML
Lennart Regebro wrote: > On 2/13/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > > Yet again looking for comments, this time at: > > http://dev.zope.org/Zope3/OneNamespaceForZCML. > > What happens if you want to add your own statements? Should you still > do that in your own namespace? No. But I don't think that it'll be much of a problem. I expect that not a lot of 3rd party packages will need their own set of ZCML directives. I would certainly not encourage it and I will continue not to document it in my book. ZCML is a good tool, but only with a certain limited functionality (that was its intention in the first place!). That includes a somewhat limited set of directives. I realize "somewhat" is fuzzy. Let me just say that I think ZCML has failed when Plone will have its own ZCML directives... > If not, how are we going to make sure we don't get conflicts? By choosing decent names for the few directives that will be necessary. I know, it sounds lame, but even *with* namespace you'd need decent names. Or does anything prevent me in my own package to register a ZCML directive called browser:viewlet? Nope. So, it doesn't make much of a difference with or w/o namespaces. Philipp This message was sent using IMP, the Internet Messaging Program. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] One namespace for ZCML
On Monday 13 February 2006 07:57, Philipp von Weitershausen wrote: > Yet again looking for comments, this time at: > http://dev.zope.org/Zope3/OneNamespaceForZCML. -1 Here some comments: - You do not argue how the decision-making process is "highly inconsistent". - I do not understand what's so bad about coming up with your 3rd-party ZCML directives. They are extremely easy to write and use. I think that 3rd-party ZCML directives are not a bad thing. And yes, I would like to keep those in a separate namespace. 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] One namespace for ZCML
On 2/13/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > Yet again looking for comments, this time at: > http://dev.zope.org/Zope3/OneNamespaceForZCML. What happens if you want to add your own statements? Should you still do that in your own namespace? If not, how are we going to make sure we don't get conflicts? I'm probably +0.1 on this. For me, many namespaces isn't a problem, but I have realized other people think they are... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
