[Grok-dev] No-ZCML story
chrism at plope.com
Sat Aug 1 15:09:43 EDT 2009
I find that having ZCML around is useful for declarations that require ordering.
Relying on import or grokker ordering for these sorts of things is suboptimal
It's also useful as an override mechanism if you're building "a framework"
rather than an application.
On 8/1/09 10:03 AM, Martin Aspeli wrote:
> Wichert Akkerman wrote:
>> On 8/1/09 1:07 PM, Martin Aspeli wrote:
>>> Christian Theune wrote:
>>>> 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.
>>> 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.
More information about the Grok-dev