Hanno Schlichting wrote: > Chris McDonough wrote: >> Maybe there's some potential to create a set of core ZCML registration >> handlers >> for utility, adapter, subscriber, and interace that are not actually part of >> BFG, but on which BFG and other non-Zope apps could depend. I suspect this >> is >> the only realistic way to go forward: I don't think it's reasonable to tell >> the >> people who have Zope apps in production which use these declarations that >> they >> won't be able to use untrusted code or permission declarations, or the global >> registry. > > Should this discussion happen on the zope-dev list or is that too > hostile these days ;)
I'd be happy if this discussion migrated to zope-dev. > >>From my point of view, configuration of components is an area where > every Zope-based project takes a different approach to right now: > > - Zope3 has its own handlers tied in deeply into the rest of the application > > - Zope2 has its own handlers (in Products.Five) which are highly > dependent on the rest of the application > > - Grok uses a different approach and has written its own configuration > approach > > - Plone might want to adopt a Grok-style approach and will need to use > yet another kind of five.grok or similar handlers > > - repoze.bfg now gained its own implementation of the core ZCML handlers > > What all projects have in common, is the abstract concept behind those > handlers and the dependency on zope.component and zope.interface. We all > have interfaces, utilities and adapters. > > What is different is the exact way these concepts need to be configured > to fit into the framework. One problematic bit is that depending on the > framework the configured result actually has different semantics at some > points as well. > > What can we do about this? > > Every framework makes it more obvious that they have different > implementations of the same concepts and provide them in a different > namespace / approach? That results in integration packages to be > required to be able to use a package from one framework in a different one. > > We all claim to be in the same namespace and let the result of the > configuration be dependent on the framework it is used in? That is more > convenient to (re-) use but has the risk of hiding the semantic differences. It just doesn't seem feasible to break backwards compatibility to make the "core" directives do less all the time. It'd work to add knobs to the core directive packages that let it detect whether the directives use more advanced features like "trusted" and "permission", but it might make the ZCA code a little convoluted. I suspect that floating that idea on zope-dev would be the only way to tell. I wonder if anyone has enough context using the ZCA outside of Zope for the idea itself to make much sense to them. - C _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
