[ZPatterns] Revisiting an old question: Reusable ZPatterns applications

[Steve Spicklemire]

Hi Itai,

	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.

On Thursday, September 13, 2001, at 07:28 PM, Itai Tavor wrote:
> I now have an opportunity to sell this application to many clients, if 
> I could modify it so that instances of it could be created quickly and 
> easily. Sadly, this seems to fall somewhere between extremely hard to 
> impossible.
>
> 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?

> 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! ;-)

> Which leaves me with the only option of rewriting the whole application 
> without ZPatterns. Not a very tempting proposition.
>
> 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".

-steve

> 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"      --
>
>
> _______________________________________________
> ZPatterns mailing list
> ZPatterns@eby-sarna.com
> http://www.eby-sarna.com/mailman/listinfo/zpatterns