-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote: > 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?
I'm not arguing (here) against refactoring the namespaces in which "core" directives are declared. I'm arguing against the idea that namespaces are bad in general. > Why is it then recommended that third-party packages use their own > namespaces, even though they might only have browser-related directives > to register...? Third-party packages which don't define new directives don't need their own namespaces. If, for instance, Plone adds a "plone:view" directive which is nothing more than a no-op wrapper around 'browser:view', that would be a Bad Thing (TM). If, however, they add a 'plone:frobnatz' directive which does something magical and outside the scope of the Zope core, and document how to use it when setting up Plone, that would be a Good Thing, especially if it kept people from changing "site policy" by customizing software. > 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. ZCML *must* support extensibility, and therefore must continue to allow packages to register their own namespaces (unless we abandon XML altogether). Otherwise, we give up the ability to check that a given directive can actually be interpreted at all, which would be a Bad Thing. >> - 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... Just note that being able to extend the configuration language from non-core code is an important use case. >> - 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. A lot of the feedback seemed to be along the lines of: - "ZCML sux -- I won't use Zope3 until it is gone!" They weren't gonna use it anyway. - "Why do I have to declare the namespaces?" (XML haters, for the most part; note that I am not an XML fanboy myself). - "Why does the core use more than one namespace?" This question seems legitimate to me: I think we wanted to allow non-mangled names for otherwise conflicting directives, e.g. 'browser:view' and 'xmlrpc:view'. >> - 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) Nope. You are ignoring the cases which are currently done TTW in Zope2: mailhost configuration, for instance, or caching policies, etc. If an application wants to add a diretive which makes it possible to configure such policies in ZCML, why should we prevent that? >> - 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. The origin of the "dead chicken" meme, was Guido (and others) who objected to the mistake-prone typing required by the earliest set of directievs we had; Guido called them "dead chickens". 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 iD8DBQFD8LP6+gerLs4ltQ4RAuoRAKCAlLEORfvO7tp120QAQhv3lTQ7JACeLgxt NeUfI9mQ5TWhRO+typeHKcg= =8EfQ -----END PGP SIGNATURE----- _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com