[Zope] Strategies for building ZPatterns applications as
python Products?
Steve Spicklemire
steve@spvi.com
Tue, 6 Mar 2001 09:00:52 -0500 (EST)
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 --