Hi Steve, I think that what I'm trying to do is quite different than EMarket. I'm trying to build an object model-based application that can be reused. And following O-O rules, reuse should happen at the level of selecting objects from the original application, subclassing some that need to be changed and completely replacing others that are not appropriate for the new application. I'm not even sure that the basis for starting a new application should be an EMarket-like class that builds everything else - rather each application needs its own top level class to encompass everything. But then even that is not necessary - because that class gets instantiated only once. So the process for starting a new application might be to create a folder and populate it with instances of Specialist-derived classes from the original application. I'm not sure that subclassing to customize can be avoided, because customizing can involve more than modifying UI methods, when features or interfaces need to be changed. In any case, I'll be subclassing anyway, because I don't want to place class methods in Specialists, so I can either create ZClasses and place the UI methods in them, or create filesystem-based classes. It seems that what I'm planning is a full application that can later be torn apart and reused, when maybe I should be trying to build a template product that can be instantiated, like EMarket. I'm not sure which approach is better. And I can't figure out how to build an EMarket-like product while providing the ability to mix different classes and change features and interfaces for each instance. Creating a new application by reusing and subclassing objects from an existing product seems more in the O-O way to me, but it does create its own problems. If anyone else is still following this thread, could you please throw in your comments, if you ever developed an object-model/Product/ZPatterns based application? Itai P.S And to the rest of the list, apologies for the growing length of this thread. Steve Spicklemire <steve@spvi.com> wrote:
Hi Itai,
I agree with many of your comments about the structure of EMarket. Factoring is hard and the current decisions about EMarket were made because I didn't want to require the user to subclass his EMarket classes from my 'special' classes.. so I put more methods in the Specialists.
Also, the EMarket approach makes a lot more sense in the context of ZCVSMixin (which I also use a lot!) for 'sync'ing development and production servers.
Also, putting methods/dtml in the instance is harder than leaving them in the Class! If you want something to be *not* editable ttw, just set it as a class attribute in your Product. But then you've got to edit filesystem based code to customize... which means you need subclass to customize.
Also.. (my last also.. I promise!) EMarket doesn't require ZClasses, it just requires DataSkins (any DataSkin subclass should do). I've got one EMarket running now.. where most/all the EMarket integration was done as SkinScript...
The Refresh product makes doing more at the Product level a bit more bearable as well... but it seems to me that you'll need to subclass your application every time you want to customize it... is that the plan? This seems to have problems of its own.
take care, -steve
"Itai" == Itai Tavor <itai@optusnet.com.au> writes:
Itai> Hi Steve,
Itai> Thanks. I've looked at all the ZPatterns-based products I Itai> could find when I started thinking about making this Itai> transition - and EMarket was the first I looked at.
Itai> The problem is that there are some things in the way EMarket Itai> is organized that I don't like - which is why I'm looking Itai> for a strategy that would work better for me.
Itai> When you create a new EMarket instance, all dtml methods get Itai> installed in the instance, and from then on all Itai> customization gets done ttw on the instance. This is fine Itai> for a product that users who are not experienced in python Itai> product editing are expected to take and use as-is and only Itai> customize the UI. But in my case, the application is Itai> expected to be heavily customized for both features and UI Itai> for every instance, and does not need to be simple enough to Itai> be managed by a non-programmer. So moving a large part of Itai> the application into the instance doesn't make sense to me.
Itai> Also, I'd like to keep UI code that displays class instances Itai> where I think it belongs - in the class, rather than in the Itai> Specialists as in EMarket. So I either create ZClasses and Itai> place the UI methods in them, or keep the UI in the Itai> product. And requiring ZClasses, the way EMarket does, is Itai> another thing I want to avoid, when I can have the product Itai> manage all classes on its own.
Itai> So... I guess I either need to be convinced that the EMarket Itai> structure is indeed good... or get some confirmation from Itai> anyone that a more product-centric approach is appropriate Itai> (and workable).
Itai> What really bothers me is that if I end up with a lot of Itai> methods in the instance, I lose much of the benefit of using Itai> a product. For example, I can't make changes on a test Itai> server and then upload the new product to the live server Itai> while retaining existing data - I need to copy individual Itai> methods instead.
Itai> Itai The Infinitely Confused
Itai> 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> -- 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 Tavor -- "Je sautille, donc je suis." -- itai@optusnet.com.au -- - Kermit the Frog -- -- -- -- "Every day, once a day, give yourself a present" - Dale Cooper --