Hanno Schlichting wrote: [snip] >> 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 opportunities. 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. Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
