Corey wrote:
Appologies if some of these questions seem naive, I'm just beginning to more thoroughly delve into zope3 - of which I've been very impressed so far.

However - is it just me, or does zope3 seem to require a rather massive amount of configuration?

Zope has always required a fair bit of configuration. In Zope 2, this has
largely been burried in the Python code, making Zope 2 Python code especially
Zope specific.

Is that specifically an artifact of Component Architectures in general? Or is this by design?

The component architecture adds some configuration.

Also, a goal of Zope 3, especially the Zope 3 application server is to make
it possible to override components without changing Python code.

Having said all of that, zcml also reflects the unavoidable process of
getting things at least somewhat wrong at first.  Over time, zcml has evolved
and gotten easier to deal with.  In particular, we are now in the process
of simplifying zcml in a number of ways:

- Zope 3.1 has many fewer component types and thus fewer zcml directives.
  Most components can now be registered with utility and adapter directives.
  Old directives are still supported for backward compatibility, but over time,
  I expect the vocabulary of ZCML directives to shrink quite a bit.

- Starting in Zope 3.1, it is possible to declare interfaces adapted in
  Python and adapter and utility directives can use information defined in
  Python for required and provided interfaces.  For example, most of
  my adapter directives now look like:

     <adapter factory="..." />

  I can make declarations in Python that aid interpretation of the Python
  code and I don't have to repeat those in zcml.

- zcml was intended for configuration, but, in our attempts to make things
  easier, zcml has taken on a definition role in many areas.  For example,
  a number of common directives, like browser:page, browser:editform,
  browser:addform and so on *define* new components as well as registering
  them.  Our (ZC's) package is a rection to that that moves definition
  back into Python, where it belongs, allowing much simpler configuration.

Are "site administrators" really supposed to understand all that zcml in the configure.zcml files, or are they more realistically the domain of component developers?

They are the domain of component developers, who develop base configurations,
and integrators who might overide configuration when integrating a package
of components into an application.

> It seems to me that the configure.zcml looks almost as if it
would basically be considered "hands off", once the application/component was coded and installed.
> Generally how much of any particular configure.zcml could - practically
> speaking - be modified in a usefull manner?

In particular, a consumer of a package never modifies the zcml, however,
as mentioned above, an integrator might override some of the configuration
in theor own zcml.  How much gets overridden depends on the needs of the

Even for relatively smallish apps, such as the buddydemo and zwiki, the configure.zcml file seem quite large; I hate to imagine what a more involved and complex app would do.

Am I just looking at it wrong? Perhaps the basic idea is small amounts of code, and large amounts of configuration/meta-programming via zcml?

For both of these apps, there is much less zcml code than Python code.
The zwiki app has an unusual amount of security policy in it. In fact,
it has way too much, IMO. For one thing, it depends on a particular
security policy.  If a site uses a differeny security policy, they
will have to actually rewrite the zwiki zcml file.

The buddydemo application has *very* little application logic,
which tends to inflate the configuration/code ratio.

For 3.1, both of these packages zcml files could be shortened a
fair amount.


Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-users mailing list

Reply via email to