[Zope3-dev] ZCML alternative

[Jim Fulton]

Shane Hathaway wrote:
> 
> Jim Fulton wrote:

...

> >>Some specific problems with ZCML:
> >>
> >>- It's hard to find the code that processes a given directive.
> >
> >
> > Why is that important to the users of ZCML?
> 
> Primarily to find out the required and optional attributes, but also to
> find documentation on a directive.  The documentation is likely to be
> located near the implementation, but namespaces don't translate to
> Python package names, so it's hard to know where to look.

The answer to this problem is to provide documentation. If site managers have
to read Python source to figure out how to configure Zope, we're doomed.

 
> >>- It's hard to tell what a ZCML file depends on without reading every line.
> >
> >
> > I have no idea what you are saying here. Could you explain what you mean?
> 
> A configuration file can import things from any Python package, and many
> directives perform imports.

The imports are quite clear. I agree that you have to look at the dotted
names to see what's being imported.

Your example actually hides most dependencies in the 
Configuration base class.
 
...

> >>- We've had to invent syntax to cover things that XML does not address,
> >>like Python imports and lists.
> >
> >
> > I don't see that this is much of a problem. In fact, I find the
> > dotted names easier to use that Python imports in a alot of ways.
> 
> I concur, but it's more for folks to learn.

No, it's less for folks to learn, because they don't have to learn Python.

 
> >>I'd like to suggest that configurations are objects.  Object
> >>encapsulation gives you separation.  Besides being objects,
> >>configurations are also components, so they implement an interface.
> >>With that in mind, I took the JobBoard ZCML file and rewrote it as a
> >>Python class.  I liked the results.  I'm sure there are typos.
> >>
> >>The approach provided easy answers to a lot of the ZCML syntax issues.
> >>register() is the one method required.  Namespaces weren't really
> >>needed, so I didn't use them.  There are groupings in the ZCML using
> >>comments, so I turned those into separate methods.  I used Python
> >>imports instead of ".xxx.".  I used lists.  I avoided using Python
> >>keywords as argument names through the use of positional arguments.
> >>
> >>Comments?
> >
> >
> > Here are what I consider some important goals of ZCML:
> >
> > 1. Configure is separate from software
> >
> > 2. The configuration language is used by site managers,
> >    not developers. Many of them don't know Python. It's
> >    my guess that more of them understand XML syntax than
> >    understand Python syntax.
> >
> >    The simplicity of XML is a big advantage here. Python is
> >    too expressive. People who know Python will use clever features
> >    that site managers will never grok.
> >
> >    The real complexity in any syntax is the semantics, which need to
> >    be well explained. We need to do a better job of that, but heck,
> >    we're working as fast as I can.
> 
> So, you're saying we need to strongly discourage component developers
> from developing configurations that are difficult for site managers to
> customize.  I agree.
> 
> I'm looking at the Site Manager definition:
> 
> http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/SiteManager
> 
> The page doesn't specify whether Site Managers do their customization
> work through the web, but I think they do.  Through the web, they will
> not edit XML nor Python; they will interact with pages and forms that
> will guide them through the process of customization.

For some time to come, site managers will do configuration with
configuration files.
 
> That's why Chris Withers and I suggested configurations are not files,
> but objects.  ZCML might be one way to create a configuration object.
> Python code might be another.  You could store configuration objects in
> ZODB.

There will be TTW configuration at some point. This configuration will be
stored in the ZODB. It's unclear what interface site managers will use to
create this configuration, although I'm 99% sure it won't be Python.
 
> > 3. Site managers need to be able to *override* configuration
> >    without changing the original configuration source. That
> >    would be very hard to achiev in Python. In fact, a lot of
> >    the difficulty in figuring what's going on under the hood
> >    and debugging zcml arises from the delayed execution
> >    needed to make this work.
> 
> You can still use delayed execution in Python, as in the example I
> attached.  It seems as easy to override using the syntax I suggested as
> it is in ZCML, but maybe you're seeing something else.

But if you do delayed execution, you will introduce complexities that defeat
the transparency you wish to achieve by using Python.
 
> The real question lies in our expectations of site managers, I think.
> I envision people who do any significant work on the filesystem to be
> component developers. 

Site managers live there too.


> Site managers would prefer to work through the
> web. 

Some would, some wouldn't.

Jim

--
Jim Fulton           mailto:jim@zope.com       Python Powered!        
CTO                  (888) 344-4332            http://www.python.org  
Zope Corporation     http://www.zope.com       http://www.zope.org