[Grok-dev] No-ZCML story
Martin Aspeli
optilude+lists at gmail.com
Sat Aug 1 10:03:39 EDT 2009
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
More information about the Grok-dev
mailing list