-----BEGIN PGP SIGNED MESSAGE-----
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
- 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 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
-----END PGP SIGNATURE-----
Zope3-dev mailing list