Re: [Zope3-dev] Re: Reducing the Amount of ZCML Directives ready for review
Tres Seaver wrote: Philipp von Weitershausen wrote: The case of class/factory is arguable, I admit. However, there I'm just following the rule of a) defining things in Python and registering them in ZCML and b) use more basic ZCML directives, less special ones. I think we could argue the following equally well: if you find a directive unuseful, *just don't use it*. Such a practice, while allowing co-existence of different viewpoints, hinders reuse of components among different developers. If a pool of independent components use different directives to accomplish the same thing, to integrate them into my project I need to understand how most of those directives work. Parties ignoring differents sets of directives encourages islands of development and henders communication. -Jeff ___ 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: Reducing the Amount of ZCML Directives ready for review
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Dominik Huber wrote: I really appreciate your effort in all other cases, but in this case I think its not a simplification. At least in case of class/implements it is. I'm merging two directives, class/implements and five:implements into one. The case of class/factory is arguable, I admit. However, there I'm just following the rule of a) defining things in Python and registering them in ZCML and b) use more basic ZCML directives, less special ones. That rule is somewhat debatable (the debate seems ongoing). I think we could argue the following equally well: if you find a directive unuseful, *just don't use it*. Register *new* directives (perhaps in a new namespace, if you want to reuse the names) which do your simpler / cleaner thing. Deprecation is not always a reasonable model, given disagreement about the value of the simplification. + 1 ___ 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: Reducing the Amount of ZCML Directives ready for review
Philipp, I really appreciate your effort in all other cases, but in this case I think its not a simplification. The today's arrangement of class subdirectives is not an evil at all. We use all offered subdirectives (including implements and factory) heavily in our use cases. IMO It's important that nested directives embrace things belonging together. This enhances readability of the grouping and reduces redundant reference-informations. That's also a very important aspect of usability. I would be annoyed about the proposed changes. Regards, Dominik Philipp von Weitershausen wrote: Dominik Huber wrote: Philipp von Weitershausen wrote: * class/implements and class/factory weren't removed -- yet. I guess removing these might be a bit controversial. I'd therefore like to take this opportunity to bring this topic up again and to give everyone a chance to look at the proposal once again, before I start spending lots of time on the implementation. I'm -1 on moving implements out of the class directive Why? With a top-level implements directive, we get to deal with more general cases (not only classes can implement interfaces, functions can too). It will also let us get rid of the Five-specific five:implements directive for which there seems to be no good reason to be in the five namespace. With Reducing the Amount of ZCML Directives I'm looking mostly at consolidation of the existing stuff. It's ok to *introduce* a top-level implements, but not to *move*. and I'm still -1 on removing the factory subdirective. Would you care to explain why? I couldn't find a previous comment from you on that. [Zope3-dev] Simplify Skinning ready for review / work on Reducing the Amount of ZCML Directives http://mail.zope.org/pipermail/zope3-dev/2006-February/018376.html Dominik Huber http://mail.zope.org/pipermail/zope3-dev/2006-February/018384.html Dominik Huber ___ 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: Reducing the Amount of ZCML Directives ready for review
Dominik Huber wrote: I really appreciate your effort in all other cases, but in this case I think its not a simplification. At least in case of class/implements it is. I'm merging two directives, class/implements and five:implements into one. The case of class/factory is arguable, I admit. However, there I'm just following the rule of a) defining things in Python and registering them in ZCML and b) use more basic ZCML directives, less special ones. The today's arrangement of class subdirectives is not an evil at all. Oh, I never said it was evil. It was just a lot of mixed stuff. The 'content' or 'class' directive always seemed to me like its creator thought Hmm, let's see, what else can we do with classes? That disturbed me. I'd like ZCML directives to preferrably do one thing only. With my proposal, the 'class' directive would be reduced to just doing security declarations, which is what it's usually used for anyways. The rest of stuff in 'class' (factory and implements) has absolutely nothing to do with security declarations... We use all offered subdirectives (including implements and factory) heavily in our use cases. Sure. Zope 3 heavily used the 'vocabulary' directive as well until last Sunday. That doesn't mean it shouldn't have been removed, though. It's not like I'm proposing to take away functionality. I'm just proposing to implement it differently. IMO It's important that nested directives embrace things belonging together. Indeed. Right now, 'class' mixes quite separate things (security vs. a utility registration vs. interface declarations). This enhances readability of the grouping and reduces redundant reference-informations. That's also a very important aspect of usability. Yes. Another important aspect of usability is *re*usability. If I can apply something I learned before in a different context, then a system is very usable, I think. That's why people love the Mac. It's so consistent. ZCML isn't very consistent. At least before my proposal was partially implemented, I could think of a dozen ways to register certain utilities. There still are a dozen ways to register adapters. To make my point, let me quote Tim Peters echoing Guido's thoughts: import this ... There should be one-- and preferably only one --obvious way to do it. ... 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
[Zope3-dev] Re: Reducing the Amount of ZCML Directives ready for review
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp von Weitershausen wrote: Dominik Huber wrote: I really appreciate your effort in all other cases, but in this case I think its not a simplification. At least in case of class/implements it is. I'm merging two directives, class/implements and five:implements into one. The case of class/factory is arguable, I admit. However, there I'm just following the rule of a) defining things in Python and registering them in ZCML and b) use more basic ZCML directives, less special ones. That rule is somewhat debatable (the debate seems ongoing). I think we could argue the following equally well: if you find a directive unuseful, *just don't use it*. Register *new* directives (perhaps in a new namespace, if you want to reuse the names) which do your simpler / cleaner thing. Deprecation is not always a reasonable model, given disagreement about the value of the simplification. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEHrCD+gerLs4ltQ4RAnb7AJ9NyTYi9roHh6IrcyoxqbEeNpuBRgCeLhm3 f6Abhf0JvAOYKZ645Ev7tCQ= =fvkA -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: Reducing the Amount of ZCML Directives ready for review
On 3/20/06, Tres Seaver [EMAIL PROTECTED] wrote: I think we could argue the following equally well: if you find a directive unuseful, *just don't use it*. Register *new* directives (perhaps in a new namespace, if you want to reuse the names) which do your simpler / cleaner thing. Deprecation is not always a reasonable model, given disagreement about the value of the simplification. Good point. I think one major goal here (which to me seems to be reasonably satisfied by the proposal) is to make it easier to *use* zcml, more than to just make it smaller (which I think is a reasonable secondary goal). I put down some effort to make something similar to the faster-better-cheaper benchmark with Zope3, without copying existing code or skeleton code (although I didn't do timelogs, I did a contact-list, but that changes nothing in level of difficulty). And without any doubt, it's ZCML that is the big problem here, providing at least 2 out of 3 headaches. In fact, I only had one minor Python headache (I forgot that the object needs to be contained) and several rather major ZCML confusions. There are too many ways of doing things that sound like they possible may be the right way, but aren't. Simplficiation of this can be done in two ways: 1. Getting rid of the wrong ways. 2. Adding one new obviously correct way. Or any kind of mix of this. Note: The following is not a proposal, just reflection: What I ended up with was this: content class=.contact.Contact require permission=zope.Public interface=.contact.IContact set_schema=.contact.IContact / /content browser:defaultView for=.contact.IContact name=edit.html / browser:addMenuItem class=.contact.Contact title=Add Contact permission=zope.Public for=* / browser:editform for=.contact.IContact schema=.contact.IContact title=Edit Contact permission=zope.Public name=edit.html / Not too complex. But I did run up several wrong paths, like addform. And worse, addview, which as noted doesn't seem to even work, and is not needed in any case. But it's not obvious that you need neither an addform or an addview. I'm wondering if maybe this could not be simplyfied into something more like: content class=.contact.Contact viewing permission=zope.Public defaultView=edit.html / editing title=Edit Contact permission=zope.Public name=edit.html schema=.contact.IContact (with an optional view or template of you don't want a default edit form) / adding title=Add Contact permission=zope.Public for=* (with an optional view or template or interface if you want an add form) / /content This doens't really make the number of statements smaller, and it doesn't save very many lines of ZCML. But it *does* make it pretty darn obvious what to do. Because you can't do much else. Note again that this is not a proposal. I'm not saying we should do this. I'm just saying that simplifying can be done in several ways, and this would be one (not nessecarily good) way. (In fact, I think I like this, but it can without any problems be made into a separate product that adds this statement to ZCML, for simplified product creation). -- 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
[Zope3-dev] Re: Reducing the Amount of ZCML Directives ready for review
Tres Seaver wrote: I really appreciate your effort in all other cases, but in this case I think its not a simplification. At least in case of class/implements it is. I'm merging two directives, class/implements and five:implements into one. The case of class/factory is arguable, I admit. However, there I'm just following the rule of a) defining things in Python and registering them in ZCML and b) use more basic ZCML directives, less special ones. That rule is somewhat debatable (the debate seems ongoing). Well, it's a rule (my rule :)), the question is whether it's one that we officially want to use ;). Yep, the debate is ongoing. Unfortunately, I don't have time for the debate. I need to solve problems. Like, for example, explaining someone in a book that utility / registers a utility, except when you're doing factories, DAV interfaces, vocabularies, etc. etc. Of course, they're all looked up the same way, namely with getUtility. Well, that's just great. I think we could argue the following equally well: if you find a directive unuseful, *just don't use it*. Register *new* directives (perhaps in a new namespace, if you want to reuse the names) which do your simpler / cleaner thing. Ok. Let's call that the Tres rule :). I'd just say: Use Python constructs until your unuseful directives become useful again. I find utility / extremely useful. Deprecation is not always a reasonable model, given disagreement about the value of the simplification. Deprecation wasn't objected for the other directives (the top-level ones), so at least for the majority of the directives in question, deprecation and eventual removal does seem to be a reasonable model. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Reducing the Amount of ZCML Directives ready for review
Philipp von Weitershausen wrote: If no one objects to the branch as it is, I will merge it on the weekend. Done now. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Reducing the Amount of ZCML Directives ready for review
On Fri, 17 Mar 2006 08:56:54 -, Martijn Faassen [EMAIL PROTECTED] wrote: Before this merge goes through, I would propose the following steps: Take the document and edit it so it's a clear guide for what you should do with broken directives. I.e. for browser:localUtility we want to exactly specify what needs to be done to register this with the normal content directive. After that, this document needs to be checked in under the doc directory. Finally, there needs to be a clear pointer in at least the changelog as well as the release notes to this document. Is there a DTD or XML Schema for the core ZCML namespace(s)? If not, I think this should happen at the same time, and I'd suggest it be appropriately annotated to serve as documentation. Interfaces aren't just for python code :) Martin -- (muted) ___ 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: Reducing the Amount of ZCML Directives ready for review
Martin Aspeli wrote: On Fri, 17 Mar 2006 08:56:54 -, Martijn Faassen [EMAIL PROTECTED] wrote: Before this merge goes through, I would propose the following steps: Take the document and edit it so it's a clear guide for what you should do with broken directives. I.e. for browser:localUtility we want to exactly specify what needs to be done to register this with the normal content directive. After that, this document needs to be checked in under the doc directory. Finally, there needs to be a clear pointer in at least the changelog as well as the release notes to this document. Is there a DTD or XML Schema for the core ZCML namespace(s)? If not, I think this should happen at the same time, and I'd suggest it be appropriately annotated to serve as documentation. Interfaces aren't just for python code :) Feel free to submit a patch. I'd recommend using Relax NG for this. It shouldn't be too hard to deduce a Relax NG schema from the information that's already in the code - ZCML directives have Zope schema definitions. Anyway, I wouldn't feel that this is a requirement for Philipp's changes. Good communication about what changed is, in my opinion. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
