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

[Steve Spicklemire]

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 )