[ZPatterns] The future of ZPatterns and LoginManager

[Phillip J. Eby]

At 06:00 PM 3/7/02 +0100, Johan Carlsson [Torped] wrote:

>Hi all,
>I finally got the opportunity to use ZPatterns in a project
>and am quite please with the result (after the mandatory wrestling :)
>
>Anyway, I would like to use both ZPatterns again as well as LoginManager,
>but I feel somewhat of a doubt what they will be around in the future and 
>in Zope 3.

That doubt is accurate.  See http://telecommunity.com/TW/IPC9Talk.htm for 
details.



>So, are they?

ZPatterns is not truly supported by me for Zope versions past 2.3.  That's 
because the few production apps I have using it are still on Zope 2.3.  The 
community (Steve Alexander, mostly) has contributed patches for 2.4 and 
2.5, but all I've done is incorporate some of them into CVS; I've been 
reluctant to release new versions that I can't really support.


>Or what I really want to know, is it safe to base my applications on ZP/LM 
>or is it
>something I'm going to regret?

AFAIK, many people are still using ZPatterns, as it is still a pretty good 
platform for Zope 2.x versions.  We have found, however, that it does not 
do well with applications that have very complex domain<->datamodel 
interactions and triggers.  For example, our largest ZPatterns app -- the 
one that made us realize we needed to do something differently -- is an 
equipment inventory system that tracks history of where things have been, 
and automatically changes items' status as they are moved around, etc., for 
hierarchical combinations of equipment.  (E.g. hard drives in computer, 
hard drives move when computer moves, change status when computer changes 
status, events logged showing when it is put into or taken out of the 
computer, etc.)

This involves a *lot* of SkinScript and associated routines.  Ty was able 
to throw together this engineering marvel using ZPatterns in just a couple 
of months, but the maintenance has been a nightmare ever since.  ZPatterns' 
implementation is just too complex, and too implicit.  It has the same 
failings, in a sense, as Zope 2, and goes against the Zen of 
Python.  (Notably "Explicit is better than implicit", and "if the 
implementation is hard to explain, it's probably a bad idea.")

Changes to the application have been a lot harder than we thought they 
would be, as it is altogether too easy to break something in the tightly 
coupled and carefully balanced house of cards known as "triggers"...

The *idea* of ZPatterns, in the sense of what's there, how you organize 
apps, etc., have all been proved valid, I believe, by the people who've 
used it and by our own experiences with it.  The *implementation* of 
ZPatterns, as a Zope 2-based and through-the-web development tool, however, 
is flawed.  Some of the flaws are driven by Zope 2's  shortcomings, but 
others are due to me personally having more Zope Zen than Python Zen.

I have learned my lesson, however.  TransWarp is about as Pythonic as I can 
make it, and it is not dependent on Zope or a through-the-web development 
paradigm, though it should be quite usable with ZPublisher 2 or Zope 3, and 
it should be adaptable to through-the-web use for component instantiation.

Check out TransWarp Central at http://telecommunity.com/TransWarp/ for more 
information about TransWarp, which will offer a ZPatterns alternative for 
Zope 3.