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
maxm@normik.dk said:
Hmm, maybe it's the time for a translate-zPatterns-to-english effort? I'll give it a try:
Thanks for the effort, but I'm an application server architect myself so I do understand the things that zPatterns tries to solve. It's not about understanding, my issue with zPatterns is that for every thing in the whole product, a new name has been made up. It sounds extremely interesting of course, and one could probably get a lot of VC capital out of it ;), but for daily work it's just too cumbersome. So what I'd like is that a "Rack" is called a "StorageContainer" (or whatever), a "Skin" might better be called an "Aspect", etcetera. As far as I can see, there's nothing really new in terms of "computer science new" in zPatterns, so it should be possible to find plain terms for all the various components. Until then, I think I'll stay away from it - rather have a more basic application that I can understand than something I need a dictionary for to translate. I rather build quality software than be hip, but then I'm quickly getting to be an old hat in this business... -- Cees de Groot http://www.cdegroot.com <cg@cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B
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
Steve Alexander wrote:
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!
Just to clarify this: I'm not suggesting that the controller's responsibility includes validating data. Rather, I mean that you can use SkinScript to easily add an "aspect" of validating data in a certain way. In MVC terms, this is like a wrapper around the model that validates the data. All connectors from controllers to the model must go through this wrapper. -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net
From: Steve Alexander
I found your discussion of ZPatterns terms very thought-provoking.
Thanks. The first positive comment about it :-) Your reply seems thorough. I will read it through in a day or two. (Has a deadline right now.)
Max, I'm extremely impressed! When I first read through your explanation, I figured you were a regular ZPatterns user :-)
No such luck. I am too busy right now to learn new stuff. Has to get a project or two out the door first. But it sounds very interresting so I will give it a go in the beginning of the new year. Regards Max M Max M. W. Rasmussen, Denmark. New Media Director private: maxmcorp@worldonline.dk work: maxm@normik.dk ----------------------------------------------------- Specialization is for insects. - Robert A. Heinlein
participants (4)
-
cg＠cdegroot.com -
Max M -
Max Møller Rasmussen -
Steve Alexander