[Zope3-dev] what is ZCML?

[Jim Fulton]

Martijn Faassen wrote:
> Jim Fulton wrote:
> 
>> Martijn Faassen wrote:
> 
> [snip]
> 
>>> as configuration in Python code is more flexible and packages can 
>>> form a more self-contained whole.
>>
>>
>>
>> Wrong!
>>
>> This is an important point. No one in the know is proposing
>> using Python for configuration.  Python is for definition,
>> not configuration.
>>
>> The problem with some of the high-level ZCML directives is that
>> they performed *definition* in addition to configuration.
>> For example, browser:page creates new classes.
>>
>> It's important that definition be done in Python. Configuration
>> should be done in ZCML.
> 
> 
> Okay, since I'm wrong, I think it would be useful if you spelled out the 
> difference between definition and configuration.

Admittedly, the distinction is not always crisp.  Similarly, the
difference between "low-level configuration for programmers" and
"high-level configuration for adminstrators" is not always crisp.

The philosophy is important though.  ZCML is configuration, not
definition.  Generally, Python is for definition, although, sometimes
other languages are used too. Obviously, template languages are used
for definition too.  Tres has argued that declarative languages might
be better for defining interfaces.

Also, XMI is an interesting case, as it, potentially, fills both roles. :)

 > I have some intuitions
> but it's obviously not fully clear to me, and I suspect others may also 
> have difficulty. I'll phrase give examples of things that I could 
> interpret as configuration or as definition.
> 
> Which of the following is definition and which is configuration (or 
> something else entirely?):
> 
> * Specifying which pages can be viewed for an object providing a 
> particular interface.

Low-level configuration

> * Attaching annotations to objects of a particular interface.

Saying that we want to use a particular adapter is configuration.

Implementing that adapter is definition.


> * Attaching menu entries to objects of a particular interface.

Low-level configuration. Defining the menu entries is definition.

> * Setting the layer a view is in.

Low-level configuration.

> * Specifying which page template is used to render a particular view.

Low-level configuration

> * Setting the permissions needed to access the attributes of an object.

Low-level configuration

> * Setting up the indexes in a catalog.

definition

> * Setting up a catalog for a site.

Creating the catalog is definition, registering it is configuration

> * Determine what is shown in which columns are shown in a table on a web 
> page.

Definition

> * The initial sorting order of these columns.

Grey :)

> * The batch size of a particular batched view.

Grey

> * Which resources should be included in a web page displaying a certain 
> widget.

I don't know what this means.

> * The relational database we've connected our application to.

High-level configuration

> * The mailserver we've connected our application to.


High-level configuration


> * The fields that show up in a form.

Definition

> * Setting up which fields that show up in a form are required.

Definition

> * Setting up which file extensions we want to allow to be uploaded into 
> a file upload widget.

Grey.  I would expect that you might also want to define handlers
for these.  So you'd define the handlers and configure their use.

> Perhaps these questions are too high level and should be split up into 
> multiple questions.
> 
> What criteria do you use to determine whether something is definition or 
> configuration?

It's hard to say without repeating the words or synonyms. :)

If it's


> I also suspect that some of these are local or application specific 
> configuration. It makes sense to store some configuration in the ZODB, 
> and thus, at present, not express it in ZCML at all.

Yes.


 > What is
> configuration sometimes depends on the application in question.

Yup

>> Should there be high-level directives in ZCML?  I don't think they should
>> be disallowed, but you really have to ask yourself if the automation 
>> they provide is worth the extra burden of understanding what they do.
> 
> 
> The other drawback of using ZCML for automation is that complicated 
> automation is often quite cumbersome to express in ZCML.
> 
> Another drawback is that such automation often combines various bits of 
> python code with ZCML and you have to look at multiple files instead of 
> just one.

Yup.

BTW, a general thing to keep in mind:

- Indirection and abstraction are inherently bad because they
   hide things. :)
   (This is a corolary of "explicit is better than implicit".)

- But indirection and abstraction can provide benefits that outweight
   their inherent bad-ness.

Whenever we consider ptoviding a high-level/automated facility, we have
to weigh the benefit against the inherient badness.

>> Anyway, the main thrust of the ZCML simplification is to use it just for
>> low-level configuration, not for definition.
> 
> 
> So to make it clear, you're in favor of ZCML interpretation #2, with the 
> modification that Python code should not be used for configuration but 
> definition.

Right, recognizing that I'm generally flexible. :)

> In the past, you as well were more thinking along the lines 
> of interpretation #1, correct?

Yes.  The switch to #2 was a result of experience with #1.

For specific projects, I have no problem with people chosing
high-level configuration to meet their needs.  As a general
principal, I'd rather try to keep definition and configuration
separate and use a smaller vocabulary of ZCML directives.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org