[ZPatterns] ZPatterns Extensions

Christian Scholz cs@comlounge.net
Tue, 13 Aug 2002 11:08:40 +0200


Hi!

> I am still amazed about the amount of resistance there is on the general
> Zope list to use ZPatterns but at the same time it catches a lot of Zope
> newbies' attention.  To be honest I am sick of people that just write
> off ZPatterns without motivating why, or just saying it's too difficult
> or it's not maintained.  This compels me to write a howto to illustrate
> how to do the simple things in ZPatterns, *but* I would like to test
> how all of you feel about what I have to say below.

Well, I agree, it might look difficult at the beginning but actually isn't
once you did your first app with it. I think it's not really getting
clear from the original docs how you do things.

And I've actually have written a howto which was published in Stephan
Richter's Zope book (but I actually don't know if it actually was published
in english yet. Need to ask Stephan). It basically illustrated how you use
ZPatterns to store simple ZClass object and then who to change this to
store these objects in a database via SQL.

> We have for the past 2 years invested a lot of time in ZPatterns and
> have a huge code-base that are using the ZPatterns framework.  To us it
> is still the best framework available for data abstraction and object
> collaboration in Zope and we continue to use it for new applications. 
> Although Zope3 and Peak are things to look forward too we cannot wait
> until their release and definitely do not plan to use it in a production
> environment any time soon.  In short we made the most of ZPatterns and
> wrote a number of extensions that really extended its lifetime by a
> mile.  I'll elaborate on these extensions in a while but my questions
> to you are:
> 
> 1.Are you still actively using ZPatterns?

yes, I am.

> 2.Do you think we are wasting our time writing some howtos and releasing
> extensions that can benefit especially newcomers, even though Zope3 and
> Peak are on the horison?

I don't think so. It still makes sense as Zope3 might still take some
time to arrive.

> Now our add-ons.
> 
> The first was basically taking Steve Spicklemire's idea of "levers" that
> generate SQL and SkinScript further and making a file system product of
> it.  A SQLRack (as we call it) can generate SQL and SkinScript from
> ZClass propertysheets or a filesystem Dataskin's "_properties".

Well, I developed once some product call SQLAttributeProvider which basically
was thought as an replacement for the basic skinscript for getting, updating
and deleting objects by simply giving the tablename and field definitions
and so on. Unfortunately it did not work that good in all cases so it never
became published and now I am working with some python script which takes
a database table and creates the skinscripts and sql methods as your SQLRack
seems to do (but with the ZClass props as source and not the table). Actually
I wanted to extend it that it also creates the ZClass as I usually just use
it as container for the fields and nothing else.

> The second one I find quite exciting since it solves the difficult time
> one generally has to make a ZPatterns app customisable by 3rd party
> developers.  We basically made Specialists and Racks skinnable by
> subclassing them from the CMF's SkinnableObjectManager.  To that we
> added FSSkinScript, short for filesystem skinscript.

That sounds quite cool :-) Are these products released?
For most of my apps I use some scripts on top of ZPattern which use
Formulator to edit the content of that specialist. Actually I am now
planning to move all this into some sort of python product to make it
more usable but I am still in the planning phase and don't have that much
time.

> Writing these extensions gave ZPatterns a new life for us and extended
> its usability. Naturally I got excited and just wondered if I am not
> just flogging a dead horse or if its worth pursuing this.

Well, for me ZPatterns is definitely not dead ;-)
(though I must say that I don't use it because of it's data storage
independance but more or less because of it's triggers and the possibility
to alter objects with skinscript in certain situations (like linking
other specialists to it). 

cheers,

Christian

-- 
COM.lounge                                          http://comlounge.net/
communication & design                                 info@comlounge.net