[Zope] Strategies for building ZPatterns applications as
python Products?
Itai Tavor
itai@optusnet.com.au
Wed, 7 Mar 2001 11:43:57 +1100
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 --