[Zope3-dev] ZCML alternative

[Shane Hathaway]

Jim Fulton wrote:
> What page you you refering to?

http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ConfigurationFileFormat

Thanks for listening to my ideas, by the way.  I appreciate the work 
you've put into ZCML.  I'm glad we can discuss this openly.

>>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.

>>- 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.

>>- You can't easily use debugging tools, like "print" statements, pdb, or
>>the interactive interpreter. 
> 
> 
> I assume the "you" you are refering to is the site manager (not
> the directive author), right? I think we should make there job easier, 
> but it's really unclear to me how they would want to debug a configuration.
> I don't see why Python configuration files would make thier job easier.

I was thinking more in terms of the component developer.  With Python, I 
could insert a "print" statement or set a breakpoint in a place I don't 
fully understand or which isn't working.

>>- 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.

>>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.

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.

> 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.

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 would prefer to work through the 
web.  They are not usually concerned with redistributing software, so 
exporting customized configurations back to the filesystem isn't a 
primary need.

You're probably wondering why I'm posting at 2 AM.  Well, Zope 3 is 
exciting, and my head hit the pillow but my eyes didn't close.  Had to 
join the fun. ;-)

Shane