[ZPatterns] The future of ZPatterns and LoginManager

[Johan Carlsson [Torped]]

At 10:41 2002-03-12 -0500, you wrote:


Thanks Phillip,
Interesting reading.
TransWarp really is looks interesting although I haven't
had a look at it in quite a while.

Thanks,
Johan Carlsson


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