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

[Martijn Faassen]

Philipp von Weitershausen wrote:
> 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 :).

That's true.

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

Yes, but if you need to spell out that you *don't* want the page
registrations manually, we still have to maintain those. If a new page
registration appears in Zope 3, we need to disable it again in Grok.
That's not going to work.

>> 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).

This is a whole can of worms though. The problem is that ZCML files
currently are not written with the idea that they can be selectively
disabled in mind. Any mechanism to selectively turn stuff off seems
somewhat fragile to me in the face of changes to those files. I can
imagine some kind of 'skin' mechanism where you can specify you only
want certain ZCML layers, but that would need to supported in the ZCML
files themselves.

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

Grokking Zope 3 seems not possible yet, as Zope 3 doesn't give us enough
hints. I guess you could only Grok the bits you want by also consulting
the ZCML registrations while grokking, and deduce the hints that way...
I.e. having the Grokker consult ZCML to determine what to grok, and how
to grok them. This way you could only Grok types of components you're
interested in.

Another strategy indeed would be to do all registrations ourselves, but
that seems hard to maintain as well.

Regards,

Martijn