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 )