[Zope3-dev] Re: One namespace for ZCML
tseaver at palladion.com
Mon Feb 13 11:29:47 EST 2006
-----BEGIN PGP SIGNED MESSAGE-----
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
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
> 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'
>> - 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 Seaver +1 202-558-7113 tseaver at palladion.com
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
-----END PGP SIGNATURE-----
More information about the Zope3-dev