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

[Itai Tavor]

Hi Steve,

Thanks. I've looked at all the ZPatterns-based products I could find 
when I started thinking about making this transition - and EMarket 
was the first I looked at.

The problem is that there are some things in the way EMarket is 
organized that I don't like - which is why I'm looking for a strategy 
that would work better for me.

When you create a new EMarket instance, all dtml methods get 
installed in the instance, and from then on all customization gets 
done ttw on the instance. This is fine for a product that users who 
are not experienced in python product editing are expected to take 
and use as-is and only customize the UI. But in my case, the 
application is expected to be heavily customized for both features 
and UI for every instance, and does not need to be simple enough to 
be managed by a non-programmer. So moving a large part of the 
application into the instance doesn't make sense to me.

Also, I'd like to keep UI code that displays class instances where I 
think it belongs - in the class, rather than in the Specialists as in 
EMarket. So I either create ZClasses and place the UI methods in 
them, or keep the UI in the product. And requiring ZClasses, the way 
EMarket does, is another thing I want to avoid, when I can have the 
product manage all classes on its own.

So... I guess I either need to be convinced that the EMarket 
structure is indeed good... or get some confirmation from anyone that 
a more product-centric approach is appropriate (and workable).

What really bothers me is that if I end up with a lot of methods in 
the instance, I lose much of the benefit of using a product. For 
example, I can't make changes on a test server and then upload the 
new product to the live server while retaining existing data - I need 
to copy individual methods instead.

Itai The Infinitely Confused


Steve Spicklemire wrote:

>Hi Itai,
>
>    You might be able to steal some code from EMarket for this.
>It doesn't set up custom Racks, but it does set up Specialists
>with custom methods. Note that EMarket is in serious flux, and
>that 'the basic way things are done' is changing. ZPatterns
>Zen takes a bit to grok, and my first pass at EMarket for
>ZPatterns was a tad on the early side of Zen building.
>But.. with that caveat.. I think it may represent a useful
>approach for your Product..
>
>take care,
>-steve
>
>>>>>>  "Itai" == Itai Tavor <itai@optusnet.com.au> writes:
>
>     Itai> Hi, I'm thinking about migrating my ZPatterns-based
>     Itai> application, which is currently built from standard Zope
>     Itai> components, into a python Product.  I'm looking for ideas on
>     Itai> the best way to organize the application.
>
>     Itai> I'm not trying to build a general-purpose application that
>     Itai> can be instantiated easily, but I do need to consider
>     Itai> reusing the application in the future, which will require
>     Itai> customizing features, UI, etc.
>
>     Itai> My main confusing is whether I should put everything in the
>     Itai> python product, or also have methods in the application
>     Itai> instance. Putting some methods (especially UI) in the
>     Itai> instance will make it easier to customize, but then large
>     Itai> pieces of the application are out of the product and I lose
>     Itai> the advantages that made me want to use a product in the
>     Itai> first place. OTOH, keeping everything in the product
>     Itai> requires creating a new, modified product every time I need
>     Itai> a new instance with different UI or features (this might not
>     Itai> be so bad considering that it does not get instantiated very
>     Itai> often, and that a lot of customizing work is expected anyway
>     Itai> - but it would make it hard to merge in code updates that
>     Itai> are relevant to all instances). Also, when the app is built
>     Itai> as a product it will define its own DataSkin classes, so
>     Itai> ZClasses will not be used at all - but then there's no place
>     Itai> for customizable object methods.
>
>     Itai> Another issue is that for the product to provide all the
>     Itai> code I need to create my own Racks - every Rack in the
>     Itai> application has to be a separate class which adds methods
>     Itai> and SkinScripts specific to that Rack. And every Specialist
>     Itai> needs a customized Racks management form that allows for
>     Itai> adding the appropriate Racks for that Specialist.  This
>     Itai> seems like a huge amount of work compared to managing a
>     Itai> standard objects and ZClasses application.
>
>     Itai> I'd appreciate any suggestions or description of how people
>     Itai> are dealing with these decisions.
>
>     Itai> TIA, Itai
>
>     Itai> P.S This is starting to sound a lot like the problems the
>     Itai> PTK^H^H^HCMF is dealing with using skins... but implementing
>     Itai> that kind of functionality is waaaay beyond the amount of
>     Itai> work I can afford to put in... also, skins would help to
>     Itai> customize UI, but not features, so actually copying and
>     Itai> modifying the product might be something I just can't avoid.
>     Itai> -- Itai Tavor -- "Je sautille, donc je suis."  --
>     Itai> itai@optusnet.com.au -- - Kermit the Frog -- -- -- -- "Every
>     Itai> day, once a day, give yourself a present" - Dale Cooper --
>
>
>     Itai> _______________________________________________ Zope
>     Itai> maillist - Zope@zope.org
>     Itai> http://lists.zope.org/mailman/listinfo/zope ** No cross
>     Itai> posts or HTML encoding!  ** (Related lists -
>     Itai> http://lists.zope.org/mailman/listinfo/zope-announce
>     Itai> http://lists.zope.org/mailman/listinfo/zope-dev )

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