Chris McDonough <chrism <at> plope.com> writes:
> This is a pattern that happens over and over again in Zope
> development. In my personal opinion, the original error was trying
> to make the subframework configurable at all. Instead, the
> subframework should be replaceable easily, but it should itself be
> relatively rigid. At very least, for subframeworks that really do
> require extra configuration (should be very few), this configuration
> should be done via highly specialized ZCML directives (or grokkers),
> as opposed to some very general adapter registration that can't be
> easily discerned from other adapter registrations by a newbie.
I agree very much that the various default Zope components could be
much more rigid; this would make it easier to understand the
application flow and better realize when to subclass or replace.
If rigid means less configurable, then perhaps components could be
made flexible by better adapting to the objects given to them,
e.g. use the interfaces system to tell what kind of functionality
objects inhibit and provide flexibility through this route.
As such, instead of attempting to look up a custom traverser for an
object, ask the object "do you provide your own traversal
logic?". Instead of components being primarily pluggable, they could
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -