Hanno Schlichting wrote:
>> Anything you'd actually be +1 on? :)
> I haven't figured out yet, what I'd like to do with ZCML and
> zope.configuration in general. It seems to me that ZCML is right now too
> tightly bound to application configuration. Zope2 and Five need
> different action handlers and this will continue to be the case for the
> next years and possibly forever.
I thought significant process was made on the ability to reuse more
handlers now that Zope 2 has got __parent__ support. Not enough?
> Grok has different needs for the
> configuration part of your application.
Grok does reuse some actions defined for the use of ZCML actually,
though sometimes we do introduce new ones.
> repoze.bfg takes yet another approach.
I'm sure there are new ZCML directives it introduces, but it also forked
the current ZCML directives that are in zope.component for basic
component registration, to reduce its dependencies. Perhaps that fork
can be undone if we improve the way we break things down (to anticipate
what you're saying below).
> Once we define a Grok-like API for Plone we will probably end
> up with yet some other kind of different semantics.
If you define altogether new actions that are Plone specific there might
not be too big of a problem in overlap there.
> My gut feeling is that the best long term answer would be to figure out
> how to split zope.configuration and ZCML kind of in the middle. What
> parts of application configuration are actually reusable and which are
> not. How does application configuration and system configuration like
> paste.ini and zope.conf fir together?
> Just trying to push out ZCML in itself seems better than having it stay
> in, but not what I'd consider to be a good long term answer.
I'd consider it at least a necessary step towards a long term answer, so
you should be +1 for step one. :)
Another step would be to start taking a look at refactoring the actions
to increase reuse. I think refactoring the actions can be driven by the
needs of the code that uses it. If Zope 2 developers say: hey, we could
*almost* use this action if it only didn't do this, we could use that to
split the action into two parts so that the main part can be reused. The
Grok developers and Repoze developers should look for similar
It might be that some actions very similar to the ones the repoze fork
now uses will make it back into zope.component, but that the extended
ones that Zope 3 requires should be extracted.
Note that I don't mind much that zope.configuration has intrinsic
support for ZCML (besides the general action-based configuration
system). Grok needs that support anyway, and so will any system that at
least wants to support packages that load their configuration using ZCML.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -