Hash: SHA1

Jeff Shell wrote:
> On 3/13/06, Dieter Maurer <[EMAIL PROTECTED]> wrote:
>>Martijn Faassen wrote at 2006-3-13 17:15 +0100:
>>>A newer interpretation of ZCML is:
>>>ZCML is a configuration language that configures a number of basic
>>>directives for configuring the component architecture and security:
>>>adapters, utilities, security requirements, and little else. Everything
>>>else should be done in Python code, as configuration in Python code is
>>>more flexible and packages can form a more self-contained whole. ZCML
>>>should reflect the underlying universality of the component architecture.
>>>If two directives work with, say, adapters underneath, they should
>>>really be one directive. ZCML should be simple and minimal so it is easy
>>>to grasp.
>>>ZCML is not readable standalone. ZCML is simply used to turn on various
>>>adapters and such, hooking them into the system, but we do not get a
>>>clue what the adapters are doing by just looking at the ZCML - Python
>>>code needs to be consulted.
>>>I believe that this interpretation is the up-and-coming interpretation
>>>of ZCML.
>>I hope not...
>>Note, that configuration files should be understand and
>>adaptable by administrators. Therefore, they should be readable
>>and understandable -- without an understanding of the implementation
>>(but with reading of the component documentation).
> I think differently. ZCML is primarily for programmers. ZConfig style
> configuration is what administrators deal with more, isn't it? Maybe
> ZConfig and the things in the root $INSTANCE_HOME/etc/ ZCML files.
> I don't think of ZCML as administrative configuration.

It spells out lots of site policy which must *not* creep back into the

> I'd rather have Python files that I can read and understand what's
> going on without having to consult ZCML files, directives,
> documentation, and so on, just to understand why a certain class whose
> code I'm looking at is getting its behavior when I can see no
> superclass. I'd like to know that a class I'm looking at is an adapter
> and what it provides and what it adapts without having to dig through
> a large ZCML file.
> An administrator is not likely to override my 'inplace_editor' view.

Really?  You have no options which an admin might want to change, either
on a site-wide basis or within a single folder?  How about choices like
whether to accept HTML 4.0 versus XHTML 1.0?  What about tag blacklists?

> He may want to configure global services (if my application is written
> that way) such as RDB connection parameters and mail services. But
> beyond that, just loading it up in package-includes or in a specific
> file is likely to be the bulk of 'administrative' effort.
> Did administrators go into your ``initialize(context)`` functions in
> your Zope 2 Product's __init__.py files and change things? That's what
> I view ZCML as being - a better version of that. (Better in only that
> configuration and initialization can be executed separately from
> Python imports)

We need to get beyond the idea that Python is the ideal place to spell
everything.  It is particularly bad to have to modify the software
shipped by the developer in order to change policy, which is where we
are going if we continue down this road.  Having to accept choices made
by a component developer is a barrier to reuse;  we won't win brownie
points for all our cool components if we make it hard to use a
comoponent without accepting either *all* or *none* of its configured
policy choices.

- --
Tres Seaver          +1 202-558-7113          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to