[Zope] ZPatterns

[Max Møller Rasmussen]

From: cg@cdegroot.com [mailto:cg@cdegroot.com]

>Hmm, maybe it's the time for a translate-zPatterns-to-english effort?

I'll give it a try:

Normally you talk about multi tier applications, when talking about
something like zPatterns.

Say you want to make a website where users can write articles and comments,
like Slashdot. Then in asp, or to a lesser degree Zope you will write your
application in some sort of template language. VBScript or dtml.

New programmers will mix together persistence, presentation and logic all
over the place. That is a bad idea.

When you get a little better at programming you make classes that handles
database connections, classes that handles the business logic and classes
that handles the layout. 

So in this case you will make a user table in your SQL database, an article
table and a comment table. Then you will make some logic to controll it, and
some code to view it.

This is a three tier system. zPatterns adds a few more tiers and sugar on
top.

Normally in Zope you would make an folderish article Python product or
zClass that can contain comments. And also you would make a Python product
or zClass for users. Saving their names, email, webadresses, list of
articles or whatever.

All fine and dandy. But say instead of using the ZODB for storing user data
that you want to use the database that the company allready have with
employees??? You would have to rewrite your Python product or zClass from
scratch.

To avoid this zPatterns use an anbstraction of a table called a "Rack". If
you define this Rack how it is implemented at the backend doesn't matter. It
can be an SQL database, or saved in the ZODB. The important thing is that
you allways acces the Rack the same way so any other part of your
application don't have to change when you change storage backend.

Often you want to look at data in different ways. You have your database,
your logic, and different ways to look at the data. This is called the
"Model View Controller" principle in standard Geek talk.

You use it to avoid duplication of data. The "DRY" principle (Don't Repeat
Yourself). When I see an article I also want see all comments made to this
article. Furthermore when I see a user, I also want to see the comments that
this user has made and all the articles that he has written.

Naturally you don't just copy the list of comment's to the article or the
user. This would cause redundancy and bad problems when you change values in
the original data. You make a new combined view of your model instead, where
you join articles and comments on one page. So data from two different racks
can be viewed in one place. In zPattern lingo this is called a "Specialist".
But a "view" by any other name still smells as sweet.

To use these two nice abstractions in Zope it has to work a little more Zope
like. Often when making a zClass you use a folderish object. the zPattern
folder is called a "PlugIn". It can have properties just like a normal
zClass. 

In zPatterns the interface or "property sheet" used for handling the values
in a single item in a rack. (What would be a single row in an SQL table) is
called an "AttributeProvider".

When you combine the content of one or more racks into a new Specialist (or
view, remmeber?) you use a "SheetProvider" to edit the data. This is what
would be a normal management interface in a typical web application.

Anyhoo, this is how I unerstand it.

But I must add that I have never used zPatterns, This is all from how I
understand the documentation, the Wiki etc combined with my limited
knowledge of computer science.

Hope this helps.

Regards Max M