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