[Zope] Strategies for building ZPatterns applications as python Products?

Itai Tavor itai@optusnet.com.au
Mon, 5 Mar 2001 17:04:55 +1100


Hi,

I'm thinking about migrating my ZPatterns-based application, which is 
currently built from standard Zope components, into a python Product. 
I'm looking for ideas on the best way to organize the application.

I'm not trying to build a general-purpose application that can be 
instantiated easily, but I do need to consider reusing the 
application in the future, which will require customizing features, 
UI, etc.

My main confusing is whether I should put everything in the python 
product, or also have methods in the application instance. Putting 
some methods (especially UI) in the instance will make it easier to 
customize, but then large pieces of the application are out of the 
product and I lose the advantages that made me want to use a product 
in the first place. OTOH, keeping everything in the product requires 
creating a new, modified product every time I need a new instance 
with different UI or features (this might not be so bad considering 
that it does not get instantiated very often, and that a lot of 
customizing work is expected anyway - but it would make it hard to 
merge in code updates that are relevant to all instances). Also, when 
the app is built as a product it will define its own DataSkin 
classes, so ZClasses will not be used at all - but then there's no 
place for customizable object methods.

Another issue is that for the product to provide all the code I need 
to create my own Racks  - every Rack in the application has to be a 
separate class which adds methods and SkinScripts specific to that 
Rack. And every Specialist needs a customized Racks management form 
that allows for adding the appropriate Racks for that Specialist. 
This seems like a huge amount of work compared to managing a standard 
objects and ZClasses application.

I'd appreciate any suggestions or description of how people are 
dealing with these decisions.

TIA, Itai

P.S This is starting to sound a lot like the problems the 
PTK^H^H^HCMF is dealing with using skins... but implementing that 
kind of functionality is waaaay beyond the amount of work I can 
afford to put in... also, skins would help to customize UI, but not 
features, so actually copying and modifying the product might be 
something I just can't avoid.
--
Itai Tavor                      -- "Je sautille, donc je suis."    --
itai@optusnet.com.au            --               - Kermit the Frog --
--                                                                 --
-- "Every day, once a day, give yourself a present"  - Dale Cooper --