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.
> 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:
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
That's not right. The PlugIns part of ZPatterns is separate from the
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
> 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
> 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 :-)
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -