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 be adaptive. \malthe _______________________________________________ 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 )