[Grok-dev] No-ZCML story

[Chris McDonough]

FWIW,

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 
(order=99).

It's also useful as an override mechanism if you're building "a framework" 
rather than an application.

- C

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