[Zope3-dev] Re: One namespace for ZCML
Philipp von Weitershausen
philipp at weitershausen.de
Mon Feb 13 10:30:01 EST 2006
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
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
More information about the Zope3-dev