[Zope3-dev] a new zcml directive?

[Jeff Shell]

On 3/10/06, Shane Hathaway <shane at hathawaymix.org> wrote:
> Martijn Faassen wrote:
> > If I'm doing this quite a bit, this looks like something that would be
> > better expressed in a... new ZCML directive (..waiting for the crowd to
> > start flinging stones).
>
> A possibly valid direction we haven't discussed yet is to embrace ZCML's
> flexibility and make new high level directives often.  For instance,
> every time I feel like I'm repeating myself in ZCML, maybe I should make
> a new high level directive to eliminate the repetition.  The risk is
> that configuration ends up more magical, but maybe new tools can
> mitigate that risk.  Thoughts?

No. No no no no no no no no no no no no no no no no no no no no no no
no no no no no no no no no no no no no no no no no no no no no no no
no no.

There are very few ZCML directives whose code I can read. It's way too
mystical and magical and full of weird things that I *still* don't
understand like 'discriminator'. And there are leading and tailing
underscores all over the place.

This bit me like a mother**** recently when I was trying to write a
unit test to cover a bug I found in my own code. It depended on me
setting up enough of the test environment to mimic what was happening.
It wasn't quite 'smallest unit of work' type unit testing as
could/should often be done. But it was the amount of detective work
and pain and trial and error and trial and error and trial and error
to follow so many ZCML trails to set up what I needed for my test that
really kicked off my recent round of frustration. A 3 line test, a 4
line fix, and over a hundred lines of imports / helpers / harness
support from a long day's work into the night to support those seven
lines... And really, so much of it was just trying to figure out what
the ZCML was doing and how to mimic enough of that to set things up
for my test... That's where the time was lost. I still steam up
thinking about it.

Why not provide helpful classes and functions, and make it obvious
that they're there to support programmer code, not ZCML? (I noticed
this with some of the odd little deferred factories around that get
registered as utilities for things like vocabularies). Automate
repetitive tasks with Python. I see something, theoretically, like
this as a possibility:

class AnnotationsAdapter(object):
    def __init__(self, annotationsKey, factory, assignName):
        self.annotationsKey = annotationsKey
        self.factory = factory
        self.assignName = assignName

    def __call__(self, context):
        annotations = IAnnotations(context)
        try:
            return annotations[self.annotationsKey]
        except KeyError:
            obj = self.factory()
            annotations[self.annotationsKey] = obj
            # to please security...
            zope.app.container.contained.contained(
                obj, context, self.assignName)
            return obj

# In some other module
from zope.annotations.helper import AnnotationsGetter
FOO_KEY = 'foo.key'

FooBarAnnotationsAdapter = AnnotationsAdapter(FOO_KEY, Foo, 'foo')

And then in the zcml:adapter registration, or directly in the Python
(either place above), declare the provides/adapts for this thing. I'm
sure it can be done without requiring another ZCML directive.

The bulk of my frustrations with Zope 3 have involved going down the
rabbit hole of ZCML. Whether it's just trying to understand how
something works, how I can provide a slightly different version of
'something' (ie - menu items with javascript actions), or trying to
determine whether some erratic behavior is a bug on my part or Zope's,
I inevitably end up in metaconfigure.py land. And it's the hardest
code in Zope to read - even the metaprogramming in Interface and the
sys._getframe tricks are easier to follow!

So, please no. No more ZCML for automation. Please yes only for
registration control. Please yes (or maybe) for global utility
configuration like how to connect to an RDBMS (watching the Turbogears
community start to realize that 'config.py' may not be a good thing
because certain test and documentation tools will try to run it as
Python and not set up its magic made me chuckle).

But I beg you not to add to the ZCML pile because you had to copy and
paste 12 lines of Python code. I think annotations are useful and I
ran into having to write a similar bulk of code the other day -
although my adapter and annotator had a larger separation (so
'zope:annotation' wouldn't have helped me anyways). I would argue that
most situations requiring some sort of automation can be done by Plain
Old Python Objects and Helpers and Plain Old Adapters and Utilities
that can, wherever possible, be registered in "short form" <adapter
factory="blah">.

--
Jeff Shell