[Zope-dev] More comments on ZPatterns

[Shane Hathaway]

"Phillip J. Eby" wrote:
> >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: (...)

Thanks for the suggestion, but my intention was to try it out in the
core Zope, not a product.  It seems reasonable that all ObjectManager
derivatives should have this capability, and that anything that isn't
derived from ObjectManager doesn't need it.

> 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'm finding that everything seems like deep Zen until you learn it. 
(ZPatterns comes to mind. :-) )Using ZClass property sheets, I bet it
won't be too difficult to get the plugins framework working with
ZClasses.

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

That's a great idea.  It does indeed add flexibility.  I'll try it. 
(soon. :-)

Shane