Hi Philipp. I am strongly attached to packages and software that is
reusable in and out of zope 3. Explicitly defining configuration using
decorators should keep configuration top of mind (which is where I want
to keep it when I develop) and not interfere with reuse goals. Further,
I don't have to write or format xml at all since all interaction with it
would be python.
I believe I understand where you are going with Grok development quite
well. At the same time, I recognize another approach for dealing with
the labor of component registration that could assist the zope 3
developer. Obviously this is not relying on a Grokker for its
configuration magic since you need to be explicit, but this is how I
wish to keep things.
Buildout is a wonderful tool and extending to the class level to write
the xml text that zope needs seems natural for me. I use buildout as my
setup and configuration automation tool for virtually everything from
physical server setup to configuring and building just about all the
software I use at the present time. I don't see it as the wrong place to
automate this task and to save time. Frankly, there is irony in my
configuring software in other languages using buildout but not my own
python packages in zope 3 to the level of the class.
Regards,
David
Philipp von Weitershausen wrote:
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 :).
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
