[Zope-dev] More comments on ZPatterns

[Phillip J. Eby]

At 02:29 PM 7/10/00 -0400, Shane Hathaway wrote:
>
>I decided to try out this idea.  It turned out to be a cinch!  It
>doesn't restrict the manage_* methods yet; I'll get to that after I get
>some feedback.  Thoroughly untested except on my box; use at your own
>risk, etc. :-)
>
>http://www.zope.org/Members/hathawsh/ConfigurableInstances/
>

Looks pretty good.  A suggestion, however.  There isn't any need to do it
as a patch to ObjectManager.py; you can implement this in a Product just
fine.  Just organize it like this:

class ConfigurablesSheet:
    ...

class Configurable(OFS.ObjectManager.ObjectManager):
    def _checkId(self, id, allow_dup=0):
        ...

class ConfigurablesSheets:
    configurables = ConfigurablesSheet('configurables')

class _ZClass_for_Configurable:
    propertysheets = ConfigurablesSheets()
    _zclass_ = Configurable
    manage_options=({'label': 'Configurable objects', 'action' :
         'propertysheets/configurables/manage'},)

Then all you have to do is
context.registerZClass(_ZClass_for_Configurable), and anyone mixing in
Configurable to their bases will now have the configurable stuff on your
screen.  (Btw, please don't take offense if you already knew how to do all
this; doing mixins to alter the ZClass machinery itself is pretty deep Zen
to most people, including me until just last week.  I knew the theory
before that, but only actually did some mixins like this late last week,
working on some experimental stuff for PlugIns.)


>> I think this may relate to an existing interest of yours regarding
>> specification of interfaces and overriding them in instances; I'd be
>> interested in hearing your comments regardless.
>
>The thing that's really missing is the interface that DatabaseConnector
>provides. It shows you all the methods you need to implement, and when
>you're done, the interface is ready to try out.  This leads to a sense
>of completion, which in turn makes the user pleased to be using
>Zope/ZClasses/ZPatterns/etc.  This can only be good.

Yep, it would be nice to have such a thing.  It's rather like PlugIns,
except it's designed for single methods, rather than lists of collaborator
objects.  The other comment I have, now that I've seen your approach, is
that it might be more flexible from a subclassing perspective, to use a
__replaceable__ attribute.  Here's how it could work:

1) Configurable._checkId() checks to see if the existing attribute to be
replaced has a __replaceable__ = true attribute, or if it lacks a
__replaceable__ attribute, it checks the objectmanager itself for a
subobjectname__replaceable__ attribute.

2) The Configurables ZClass mixin UI would set/reset
subobject.__replaceable__ on the list of names given (and in the case of
attribute errors would set/reset class.subobjectname__replaceable__

The advantage to this approach is that if you create mixin classes that are
designed to be added to Configurables, you don't have to go and re-check
your configurability list; the replacability lives with the methods, not
the class.