[Grok-dev] No-ZCML story

[Martin Aspeli]

Wichert Akkerman wrote:
> On 8/1/09 1:07 PM, Martin Aspeli wrote:
>> Christian Theune wrote:
>>> Hi,
>>>
>>> I just wondered: is there a wish to get rid of the small ZCML part that
>>> we need?
>>>
>>> I just realized that we could use entry points to automatically grok stuff.
>> -0.5
>>
>> I think ZCML still has its place as a *configuration* language (as
>> opposed to a component wiring mechanism for default components).
> 
> That suggests things like debug mode, port bindings, zodb location, etc. 
> should also be configured using zcml. 

I'm not sure that's quite so important (though a single syntax would of 
course be nice): those are all app server configuration items.

Permissions, GS profiles, resource directories, etc. are all aspects of 
a package. I don't see anything wrong with those being defined in ZCML.

> I don't see anyone pushing towards 
> that. Right now configuration is split over two places, and 
> configuration and wiring are mixed in zcml (and grok complicates that 
> somewhat by allowing for wiring in both zcml and code). Cleaning that up 
> by either removing all configuration out of zcml, or all into zcml feels 
> like a worthwile effort.

I don't see that happening wholesale either. There'll probably always be 
a need for ZCML. Certainly, the various application level configuration 
items will not move to ZConfig/zope.conf (nor do I think they should be).

Separately, I believe that "non-wiring" configuration (e.g. browser 
resource registrations or permissions) *should not* be defined in code. 
A Python class or other item that is never instantiated or called, but 
used only as a place to hang configuration, seems wrong to me, and is 
unnecessarily difficult to find when mixed in with other code.

That's just my preference/opinion though, and somewhat separate from the 
discussion here. However, if we recognise that some application level 
configuration should live in a file that's not a Python source file, 
then trying to get rid of ZCML is kind of moot.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book