The current issue of "Zope Guru of the Week" has closed: =================================================================== Issue #7 -- To ZClass or not to ZClass? =================================================================== Status: Closed Zen Level: Chela (4/8) Keywords: ZClasses Submitted by: Tres Seaver tseaver@palladion.com ------------------------------------------------------------------- When building a Product using ZClasses, I often want to create a "root" ZClass, which the manager will create in a normal folder, and which will then expose the Product's other ZClasses in its Add list. The DTML methods for the root are thus defined within this root ZClass. The Product ends up looking like:: Control Panel +- FooProduct + FooItem_add_permission +-FooRoot +- FooItem +- FooItem_add +- FooItem_addForm +- FooItem_factory .... +- index_html +- some_root_method_dtml + FooRoot_add + FooRoot_addForm + FooRoot_Factory + FooRoot_add_permission * What are the drawbacks to this approach? * Suggest alternatives. ------------------------------------------------------------------- Reviewed by: Tres Seaver tseaver@palladion.com ------------------------------------------------------------------- Hmmm, I don't seem to be doing so well on picking topics. Here is what I had in mind: * This site is an instance of the "ZGotW product":http://www.zope.org/Members/tseaver/ZGotW, which has a "main" factory, ZGotWRoot_factory, in its root folder. * This factory does *not* create an instance of a "folderish" ZClass, but rather, creates a normal Folder and populates it from a set of default DTML objects, along with a ZCatalog. * Individual issues of ZGotW are created within this folder as instances of the ZClass, ZGotWIssue, using the code in those "cloned" DTML objects. My rationale for adopting this approach, rather than creating a "folderish" ZClass, was to allow each instance of the "root" to be independently customized; the "common" behavior of a ZGotW site is included in a set of utility methods, which can be tweaked to enforce different policies, or change the look-and-feel of a particular site. The downside to this choice is duplication of code: should I find a bug in the original, default code, I have to then fix it in each instance as well as the Product. Comments, anyone? -------------------------------------------------------------------
----- Original Message ----- From: Zope Guru of the Week <ZGotW@palladion.com>
My rationale for adopting this approach, rather than creating a "folderish" ZClass, was to allow each instance of the "root" to be independently customized; the "common" behavior of a ZGotW site is included in a set of utility methods, which can be tweaked to enforce different policies, or change the look-and-feel of a particular site.
If a "folderish" ZClass had some way to expose its customizable parts, so that you could go to an instance and say "instantiate a local copy of method foo so I can edit it", would that better fit your intent, here? Cheers, Evan @ digicool & 4-am
Evan Simpson wrote:
----- Original Message ----- From: Zope Guru of the Week <ZGotW@palladion.com>
My rationale for adopting this approach, rather than creating a "folderish" ZClass, was to allow each instance of the "root" to be independently customized; the "common" behavior of a ZGotW site is included in a set of utility methods, which can be tweaked to enforce different policies, or change the look-and-feel of a particular site.
If a "folderish" ZClass had some way to expose its customizable parts, so that you could go to an instance and say "instantiate a local copy of method foo so I can edit it", would that better fit your intent, here?
The implementation I sketched out a version of the Prototype pattern, I think. Exposing the customizable bits is more like a TemplateMethod: this would play nicely with Acquisition, perhaps:: <!-- Inside the index_html method of a "folderish" ZClass --> <dtml-if custom_foo> <dtml-var custom_foo> <dtml-else> <dtml-var default_foo> </dtml-if> The trick then becomes giving the manager enough information to know how to implement 'custom_foo'. My current hack solves this by cloning the default bit as a starting point -- perhaps the factory could clone 'default_foo' as 'sample_custom_foo', or something? -- ========================================================= Tres Seaver tseaver@palladion.com 713-523-6582 Palladion Software http://www.palladion.com
participants (3)
-
Evan Simpson -
Tres Seaver -
Zope Guru of the Week