[ZPatterns] Revisiting an old question: Reusable ZPatterns applications

[Itai Tavor]

Hi Steve,

Steve Spicklemire wrote:

>	I think you raise some good points here, which seem to me to 
>represent areas where ZPatterns could improve, rather than 
>impossible barriers to improvement.

This is a very optimistic view, and one which I would very much like 
to be convinced of. I don't know, though... I'm looking at an 
application that could have been 95% ready for release, had it been 
written as a classic Zope Product, and instead is doing a very 
credible imitation of a dead end.


>On Thursday, September 13, 2001, at 07:28 PM, Itai Tavor wrote:
>>First, the code required to create working instances of the 
>>application would be hugely more complicated than in a comparable 
>>Zope-only application (referred to below as "normal"). In a normal 
>>application, all my  factory code has to do is to create instances 
>>of my container objects, and this will give me a full, working 
>>application. In ZPatterns, on the other hand, factory code has to 
>>install Specialist-subclassed objects, create and configure Racks 
>>inside those objects, install and populate SkinScripts, and create 
>>and populate ClassExtenders. Also, while in a normal app all the 
>>code lives in the file system, in ZPatterns I'd have to copy 
>>working application code back from the ZODB into file system 
>>modules for use by the factory code - and I'm going to have to do 
>>this every time I make a change that involves changing a SkinScript 
>>or a ClassExtender object.
>>
>
>What about distributing an "application" in a different way? Rather 
>than instantiating a Product, why not import a zexp, and then run a 
>"customization wizardish thing" that modifies various aspects to the 
>installation's taste?

Ok, interesting suggestion... I imagine the customization wizard 
wouldn't be too hard to implement. I guess in the case where several 
instances are hosted on a single server it would have to be done by 
duplicating an empty instance, rather than importing a zexp... Still 
doesn't help with updates, though... Also, thinking about what the 
wizard would have to do raises another negative aspect of ZPatterns 
for reusable applications - suppose I have a collection of objects, 
and those objects can exist as one of several variations, or classes. 
For example, an article storage system could have NewsArticle, 
PressRelease and Editorial, all stored in an Articles object manager 
or Specialist. Now, to customize the types of articles available in 
the classic Zope version of the application, I would simply modify 
all_meta_types for the object manager, and the application would not 
need to know about this. In the ZPatterns version I would have to 
program in support for this feature into the Specialist. It's just 
another example of how ZPatterns is only good for one-of applications.


>>Second, and this is where the whole thing becomes quite impossible, 
>>there's the problem of upgrading the application, for bug fixes or 
>>feature changes. With a normal app, you install a new copy, refresh 
>>the product, and you got the new application working with all your 
>>existing data. With ZPatterns, the existence of SkinScripts means 
>>that the application is mixed in with the data (at least when you 
>>use ZODB storage in your Racks), which makes smooth upgrading 
>>impossible. Basically, you're either stuck with the version you 
>>originally installed, or you have to go in to the ZODB and modify 
>>pieces of every instance - either by hand, or using ridiculously 
>>complicated upgrade code. This is really what I see as ZP's biggest 
>>problem - while it creates a logical separation between problem 
>>domain and data management code, physically it forces code and data 
>>together.
>>
>
>I've been playing with the notion of "levers" (see the ZPatterns 
>examples in my Member area that use SQL). It turns out to be pretty 
>easy, and downright nifty when for certain kinds of tasks. Using 
>these levers, and a "generic" admin interface I can whip up 
>ZPatterns apps almost as quickly as cooking up an object model. The 
>levers I am using work with ZClasses, but there's nothing magic 
>about ZClasses! I grant.. it's not out of the box ZPatterns, but 
>maybe some of these ideas could be used to improve some of the 
>nuts-&-bolts of ZPatterns, and to solve some of your upgrade issues 
>in a more automatic way. It would be great if a tool could be 
>created which could make a filesystem snapshot of a ZPatterns app 
>(basically everything *but* the data in the Racks) and update a 
>target instance of the same app with the new infrastructure without 
>disturbing the data. Really.. this is almost what ZCVSFolder does 
>(though it doesn't currently know how to separate the data in a 
>Rack, from the other stuff in the Rack). This sounds like something 
>doable.. I just need a vacation to work on this stuff! ;-)

I promise you, if I managed to get a vacation, there won't be a 
computer anywhere in sight :-)

Your levers are interesting, but I didn't (until now) see any use for 
them beyond creating SQL code out of ZClass property sheets. I'm 
still not sure how one would go about using them for other uses. What 
else have you done with levers? Do you have examples?

My typical development time for a new app, I think, is much longer 
than yours... not using levers is not really a problem because I've 
only used ZODB storage until now, and all my Racks use a Catalog, a 
standard SkinScript for cataloging and standard getAllItems and 
getAllItemIDs methods. But on the UI side I tend to spend a lot more 
time creating clear, user-friendly admin screens (you could make the 
case that I spend too much time on this side of the app), and these 
take a lot of hand-coding . No generic interfaces for this slave! 
Plus I find that an almost endless process of messing around with 
SkinScripts and interfaces is required before anything is working. I 
find that no real-world app is ever as simple or clear-cut as example 
code.

As to automated updating... a snapshot tool would definitely be very 
useful (I say that now; give me another couple of hours to think 
about it and I'll fault the idea) but I don't see one around. 
ZCVSFolder helps, but the process is far from automatic or 
fault-proof. When I've used ZCVSMixin I always had to look very 
carefully at any object to determine if it really needed updating, 
and I broke apps several times by not being careful enough. At this 
time, I don't consider it likely that I'll be able to just hit 
"Update all from CVS" at the top of the tree and get a working, 
updated app. The new recursive feature is a step in that direction, 
but 1st, it won't help when ZCVSFolder gives you false readings, and 
2nd, we haven't figured out if it will survive yet, right?

Regarding separating Rack data from other stuff... seems to me that 
that's not really a problem if you got another CVS instance in the 
Rack. You never update the Rack object, in fact you tell ZCVSFolder 
to hide Racks and use it to update objects inside the Rack one by 
one. At least that's how it works for me. One thing I still can't 
deal with is updating Catalogs using ZCVSFolder, so that the indexes 
and meta data settings get updated, but the Catalog indexed content 
doesn't. (This bit is turning into a deep ZCVSFolder usage 
discussion... it might be beneficial to have one of those, 
independent of this thread).


>>Now, I know the basic rule is to always evaluate every project on 
>>its own and choose the best tool for it. But ZPatterns did seem 
>>like a good tool for this project. Also, I don't have the time or 
>>motivation to develop parallel expertise in different methods of 
>>achieving the same goals. Focusing on ZPatterns for most of the 
>>past year has left me with quite a lot of experience and reusable 
>>code, which will be wasted if I now have to switch to traditional 
>>Zope development methods.
>>
>>Basically, the problem boils down to the fact that normal Zope apps 
>>can be developed on a one-of basis, and later changed to 
>>multiple-use if/when needed, whereas ZPatterns use seriously limits 
>>the ability for reuse. And what this means is that, unless an 
>>application strongly requires ZPatterns, it seems it would usually 
>>be best to avoid it.
>>
>>So, to sum up this long monologue.. I'm not out to criticize or 
>>blame anyone... I still think that ZPatterns is a very good tool... 
>>I'm just very annoyed to find myself feeling that focusing on it, 
>>for me at least, might have been a mistake. If anyone has any 
>>thoughts on this, I'd like to hear them. Or just tell me to shut up 
>>if you hate long monologues.

>I think these are really valid concerns/problems. I'd rather invest 
>energy in making ZPatterns more usable, than trying to convert to 
>"some other way".

I try keep the same attitude, but then, all too often I look at an 
application and realize I would have been much better off doing it 
the classic way. This work is hard enough without feeling that you're 
doing it all wrong.

Thanks for your comments! Your input is always greatly appreciated.

Itai
-- 
--
Itai Tavor                      -- "Je sautille, donc je suis."    --
itai@optusnet.com.au            --               - Kermit the Frog --
--                                                                 --
-- "If you haven't got your health, you haven't got anything"      --