[Zope3-dev] Re: One namespace for ZCML

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
   est" thread.

 - 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.
- --
===================================================================
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

iD8DBQFD8KAe+gerLs4ltQ4RAtREAJwMf91w4eEGbvp0Llz0SKg7bkoTpwCgyDce
rEhfptDFqlhXZjSAZ5FZXxw=
=aIxe
-----END PGP SIGNATURE-----