Tres Seaver wrote: > - 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.
I'm neither trying to follow the whiny people who detest XML and therefore ZCML nor am I trying to make ZCML not extensible. That said, I think that ZCML's usage of namespace is quite arbitrary. Why is browser and mail-related stuff on its own namespace but security-related stuff not? Why is it then recommended that third-party packages use their own namespaces, even though they might only have browser-related directives to register...? I don't really see the point in ZCML's using namespaces. What good do they provide? Seriously, is it just the prefix? Well, we don't need the namespaces for that. > - 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'm not sure what to do with this info... > - I don't want to encourage people to do configuration in Python: Rest assured neither do I. > 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. I have heard such feedback, otherwise I wouldn't have taken the time to write the proposal. I've also heard positive feedback on this particular matter (reducing ZCML namespaces to one). Again, I wouldn't have brought it up otherwise. > - 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. This belongs in the other thread, really. But here it goes anyway: I'm not convinced that people who deploy apps will actually go as deep as editing package ZCML, or even overrides for that matter. I would rather imagine they turn ZCML features on or off (which would then turn on or off ZCML directives via zcml:condition) > - 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. Or perhaps people just thought that people wouldn't want to type in some extra stuff. Because I think they do if it helps them remember and understand better. Philipp _______________________________________________ Zope3-dev mailing list [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
