Martijn Faassen wrote:
Jim Fulton wrote:
Martijn Faassen wrote:
as configuration in Python code is more flexible and packages can
form a more self-contained whole.
This is an important point. No one in the know is proposing
using Python for configuration. Python is for definition,
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
* 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.
* Specifying which page template is used to render a particular view.
* Setting the permissions needed to access the attributes of an object.
* Setting up the indexes in a catalog.
* 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
* The initial sorting order of these columns.
* The batch size of a particular batched view.
* Which resources should be included in a web page displaying a certain
I don't know what this means.
* The relational database we've connected our application to.
* The mailserver we've connected our application to.
* The fields that show up in a form.
* Setting up which fields that show up in a form are required.
* 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
What criteria do you use to determine whether something is definition or
It's hard to say without repeating the words or synonyms. :)
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.
> What is
configuration sometimes depends on the application in question.
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
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
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 Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list