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