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