-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephan Richter wrote: > 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?
+1 to Stephan's comment; -1 to the proposal. - The opposition to namespace declarations is whiny, as they are the standard way to make XML extensible. Unless we are going to quit using XML, outlawing namespaces would be equivalent to saying, "you may not extend ZCML"; I don't think we are smart enough to make that ukase. I think the Last Law of Python according to the Prophet Peters obtains here as well. - Note that the non-XML language also used by Zope (ZConfig) has its own extensibility mechanism: in fact, Fred and I made it possible in November for Zope2 products to register their own schemas for those extensions, which was a blocker for moving some configuration out of software. - I don't want to encourage people to do configuration in Python: we have moved away from that *on purpose* in Zope, and I don't see a reason to go back. Directives which make it possible to change policy decisions without touching software are a Good Thing. I think that letting people who spend their days up to the elbows in the software make choices here skews the picture: we *want* people to be able to change the behavior of the system in controlled ways without having to modify software; I would prefer to hear feedback from non-core-developers before going further with the "ZCML delenda est" thread. - The "application vs plugin" discussion is probably germane to this issue, as well: a user who is deploying a single application is acutally *more* likely to define and use convenience directives which reduce the amount of effort required to change policy than the generic appserver-with-plugins configuraiton. Removing the ability to create such convenience declarations makes it harder for those developers. - Many of the objected-to directives exist precisely because people did not want to type the much more verbose equivalents which were the original, "cleaner" spellings. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD8KAe+gerLs4ltQ4RAtREAJwMf91w4eEGbvp0Llz0SKg7bkoTpwCgyDce rEhfptDFqlhXZjSAZ5FZXxw= =aIxe -----END PGP SIGNATURE----- _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com