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