[Zope] ZPatterns

[Steve Alexander]

Thanks Max,

I found your discussion of ZPatterns terms very thought-provoking.

Max Møller Rasmussen wrote:
 >

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

That's right.

> 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've described the Model-View relationship.
The Controller part is where ZPatterns gets interesting; you can use 
SkinScript to do a load of validation on your data, all in one place, in 
a fairly specific and declarative language, which gets applied on 
commiting a Zope transaction. That's powerful stuff!

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

I guess that's one way of doing this.

You would have three Specialists:

   Articles
   Comments
   ThreadedDiscussions

The ThreadedDiscussions specialists would act as a view of the other two 
specialists, drawing its information from both of them, behind the scenes.

You typically use SkinScript to knit these models and views together.

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

That's not right. The PlugIns part of ZPatterns is separate from the 
Racks/Specialists/DataSkins/SkinScript part.
I think what you are describing here is makign a ZClass that is derived 
from DataSkin and ObjectManager, and then using instances of that ZClass 
in the ZODB (as you would a normal ZClass). However, if you put your 
instances somewhere below a Folder with Customizer Support, you can use 
a Customizer to play around with the attributes of your ZClass 
instances; for example, by computing them from other attributes, or 
getting them from an external database.

The PlugIns product is a tool for creating frameworks for Open 
Implementations in Zope. Basically, it is a way of adding special 
management tabs to a folder-like object, where each tab declares which 
of the folder's sub-objects it should manage. The ZPatterns classes such 
as Specialist, Rack and Customizer are built as PlugIn Managers and PlugIns.

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

It is easiest to use SkinScript to say where each attribute of an object 
needs to come from, and what should happen when someone tries to set a 
specific attribute of an object. SkinScript serves the function of an 
AttributeProvider here.

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

That's not quite right. You use a SheetProvider to link a WebDav 
propertysheet (that is attached to a Dataskin object) to some external 
data source.

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

Max, I'm extremely impressed! When I first read through your 
explanation, I figured you were a regular ZPatterns user :-)

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net