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 ;) >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. Hanno _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
