[Zope3-dev] Re: The elevator speech for Zope 3

[Philipp von Weitershausen]

On 8 Oct 2007, at 15:14 , David Pratt wrote:
> Hi Uwe. I have been thinking of something similar and posted on the  
> list a couple of weeks back:
>
> http://mail.zope.org/pipermail/zope3-dev/2007-September/023653.html
>
> I want the zcml to be generated with a switch on zc.buildout so all  
> configuration is auto generated. Currently site.zcml is done this  
> way and I want to extend this to the class level. Recipe's would be  
> produced  to handle different types of configuration by providing  
> the decorator methods.
>
> I'm hoping to use decorators exclusively on the classes to do this  
> so there would be no need to modify the code in the classes  
> themselves to accomplish the configuration.  Further, classes  
> without this decoration would be skipped by the process allowing  
> this approach to be incorporated into your code gradually. I want  
> to be able to see and verify the zcml produced and have the same  
> control over it that I have now.

We were considering the generation of ZCML briefly when developing  
Grok, but discarded it quickly. The ZCML machinery  
(zope.configuration) itself is nice, but many of the directive  
handlers that are out there are flawed. In particular, the  
browser:page handler is so awful, I'm very very happy not having to  
use it in Grok. Death to magic class creation! Other handlers have  
side-effects during parsing time (as opposed to action execution  
time). Of course, we could've always written our own directives, but  
that wasn't the exercise.

Soon, we will change Grok so that it emits configuration actions,  
rather than doing the registrations right away. That way, you will  
still be able to inspect what exactly Grok is doing (for example by  
dumping all configuration actions before or instead of executing  
them), but you won't have to deal with ZCML anymore. You will also be  
able to use the overrides mechanism with them.

> The advantage of having it in buildout is that it becomes  
> integrated into the development of the application, which is by  
> nature just the configuration glue for your packages.

I think buildout is entirely the wrong place to do this, but feel  
free to pursue your own ideas :).