[ZPatterns] Revisiting an old question: Reusable ZPatterns applications

Itai Tavor itai@optusnet.com.au
Fri, 14 Sep 2001 10:28:58 +1000


Hi everyone,

A while ago I had a discussion on the Zope list about writing 
reusable application in ZPatterns... it seemed then that ZPatterns 
reuse is limited to reusing object model patterns and code pieces. 
I'm now faced with a situation that requires much more than that, and 
it's making me question the whole choice of using ZPatterns.

I wrote an application in ZPatterns. It didn't really have to use 
ZPatterns - the amount of data would never require SQL, so the 
flexibility of changing storage was not needed. But I liked other 
benefits I got from ZP - like the way the code stays organized in a 
very similar way to the object model, how I can focus on interface 
and domain code in my classes and isolate object connections in 
SkinScripts, etc.

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.

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.

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.

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"      --