[Grok-dev] Re: RFC: Disable zope.app.rotterdam by default

Philipp von Weitershausen philipp at weitershausen.de
Wed Mar 28 02:36:39 EDT 2007


Martijn Faassen wrote:
> Currently, many Zope 3 packages ship with browser views as well as 
> non-browser configuration. The non-browser configuration we can 
> typically use just fine, but the browser configuration we cannot (with 
> some exceptions as widgets) and would prefer to be disabled completely. 

Actually, a lot of the non-browser configuration is also useless to us 
because a lot of it ends up being security declarations which Grok 
doesn't need :).

> We can always provide our own configure.zcml that copies all the ZCML. 

It might not end up being that much. Perhaps we can grok that somehow 
instead of writing ZCML :)

> This however is a maintenance nightmare in the long run as the 
> underlying Zope 3 code and its registrations can change. This might lead 
> us in the direction that was discussed previously - selectively being 
> able to turn off some registrations. Still, if you had to spell out all 
> page registrations manually, we'd still have a new, different 
> maintenance nightmare.

I thought we didn't want those page registrations?

> Changing the ZCML registrations in Zope 3 so that configure.zcml doesn't 
> include browser/configure.zcml and so on will be quite a bit of an 
> effort with risks for backwards compatibility.

One of the beefs that I have with ZCML is that there's no "exclude" 
option to tell it *not* to load certain files or packages even though 
there are include statements for them. Also, I wish it would be possible 
to say that certain components shouldn't be registered (e.g. in order to 
disable certain event subscribers).

If we'd seriously grok Zope 3 instead of using it's ZCML, we might be 
better of supporting such use cases. But we might end up in a 
maintenance nightmare, like you said... Will ahve to think some more 
about this...


-- 
http://worldcookery.com -- Professional Zope documentation and training


More information about the Grok-dev mailing list