Martijn Faassen wrote:
> I would like to highlight Lennart's point. We need to be very careful
> here. We would only have an illusion of improvement if we'd end up with
> less directives but more long dotted names into Python packages. I'd
> argue that this might make ZCML *harder* to understand, not easier.
Yes and no. I am very much for the symmetry of registering and looking up
components. If we look something up by IFactory, why should we use a named
directive that by itself has no apparent connection to that interface? For us,
interfaces have the meaning, not names. If names had the meaning, we should
look up things by names (e.g. getUtility('factory', ...)).
Right now I can take a third-party package and see that it does something like
It's pretty easy for me to come up with the necessary directive now. I know
it's a utility and I know what interface it needs to provide. I can't deduct
that I'm supposed to use <factory />.
> In fact, I wonder what a ZCML would look like that focused on reducing
> the amount of dotted names in use...
That's a good perspective, but I don't think it involves the creation of
specialized ZCML directives. You won't have to write::
if .alias.sydneyFactory already provides IFactory. The following is enough::
A good practice so far has been to keep the information that is immanent to a
particular implementation in Python. For adapters, that's the adapts/provides
combination, for utilities just the provides. For browser pages I would even
argue that the name is also immanent to the implementation (see my blog post
on ZCML needs to do less).
I would argue that this is a better way to reduce dotted names in ZCML than
coming up with specialized directives.
This message was sent using IMP, the Internet Messaging Program.
Zope3-dev mailing list