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

- 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.


Repoze-dev mailing list

Reply via email to