Roché, I was re-writing zPatterns example without zPatterns when I saw your angry comment in zPatterns mail-list about people who dislike zPatterns without explaining why. So here is my zPatterns rant: We clearly need something to represent our [relational] data in Zope. Theoretically it should be something simple since the task is very common and is solved frequently. I was very excited when I found zPatterns. It looked like the solution. It was a little strange that judging by the noise on the Internet (mail-lists, including the one dedicated to zPatterns) few people use it. Well, dogs do not always eat the dog food. On the other hand it's usually a sign. So I did my reading on zPatterns: Racks, Sheets, PlugIns, SkinScript, Triggers and so on. Occam would break his razor... Then I looked at the examples. I was surprised that with so much work I get so little. On top of everything else the example implementation did not look very elegant. Let's go over the simple use case based on the ToDo example (http://www.zope.org/Members/sspickle/DumbZPatternsExample). Imagine we have a "concept" - Doer - the person with id and email. To deal with it zPatterns way I need first to create a Doer Specialist zClass. Now, I have a problem with it: why? From my point of view Products are for meta-classes and tools. Last week there was a discussion on this list and it turned out that many people put business logic into Products but I do not like it. I see Products as infrastructure. I think Folder makes a good Product, Doer does not. I have dozens of concepts like Doer that are all data sources (tables, services, etc), I do not want to create a zClass/Product for every new one. In the ToDo example ZClass-es have some methods inside. When a Specialist is instantiated some other methods are added so you have to jump back in forth to figure out how things work. Now I need to write some data access methods. Which ones? Well, any. OK, I write some zSQLs and put them within Specialist. If later I have another data source I will have to replace my zSQLs with some other methods. What did I get from zPatterns in return for my hard work? Not much. Back to our Doer. I just wrote the same ToDo example without zPatterns. http://www.zope.org/Members/ielbert/PoorMansZPatternsExample/PoorMansZPatter nsExample.zexp - it can be imported into any Zope Folder. It uses Gadfly but should work with any database. Please keep in mind that I am a newbie and had to learn DTML just for the purpose of this exercise - I wanted to keep my example similar to the original. In real life I would use ZPT and pyscripts but it's not important. Also, to make example simpler I did not use Transparent Folders that I usually use to cleanly separate UI from my data access methods. I am very curious how Zope gurus would solve the same task. I created a table in my database called Doer. Then I created a Folder in Zope called, naturally, Doer. This Folder will be my Specialist - it will know all there is to know about Doer. I wrote a generic "get" zSQL that relies on the fact that the Folder is named the same as the table. Folder can have its own get method but if it follows the naming convention it doesn't have to. Then I wrote generic Page Template that takes results of any zSQL methods and displays them as XML (not included with an example but can be found at http://www.zope.org/Members/ielbert/zsql2zpt) Now, for a new concept (e.g. ToDo) all I have to do is to create a regular empty Zope Folder and I can immediately query it. Assuming all my tables/data-sources/racks have an ID attribute of the same type I wrote a bunch of generic methods. Of course, each Folder (Specialist) can overwrite generic methods with it's own implementation but I enjoy the immediate gratification: I create an empty Folder and right away I get some basic functionality. No Products, no efforts, no hands. Later, basic methods can be generated the Znolk way but when proper framework is defined, writing zSQL is a pretty simple task. I can also generate a set of Folders based on my DB schema but I see not problem in creating Folders manually. What do zPatterns offer to implement one-to-many and many-to-many relationships? SkinScripts? I am big fan of Demeter's Principle, which is written all over zPatterns. That's why I was surprised when I saw in the example ToDo, Doer and Deliverable intermixed within Specialists. Let's connect Doer and ToDo. Within Doer Folder I created ToDo subfolder. I gave it property "join" to indicate that it's a Folder responsible for dealing with To-Dos in a Doer context. Of course there is a ToDo Folder that knows nothing about Doer and just a Specialist for ToDo. I think it's a pretty clear separation. In other words just by providing a set of requirements for the Folders, Methods, Racks, and Attribute naming we can easily build primitive "Data-Aware" Folders. What is the value added by zPatterns? I am not sure if I made myself clear. I hope your example and how-to will show me the better way to use zPatterns. Until then I am going to expand an approach used in my example. I appreciate any comments or suggestions. Thanks, Igor -----Original Message----- From: Roché Compaan [mailto:roche@upfrontsystems.co.za] Sent: Tuesday, July 30, 2002 1:56 AM To: Igor Elbert; Chris Withers Cc: zope@zope.org Subject: RE: [Zope] Data-Aware Folder
Roché Compaan wrote:
Igor Elbert wrote:
I looked at ZPatterns and TransWarp before and did not like them. ZPatterns seem too heavy for the outcome. IMHO, the concept is good - implementation is convoluted. TransWarp is not ready. If it is going to be anything like ZPatterns, by the time the Zope community groks it, the package creators will abandon it and move to something else.
Before you give up on ZPatterns completely, look at Steve Spicklemire's examples:
http://www.zope.org/Members/sspickle/DumbZPatternsExample http://www.zope.org/Members/sspickle/SQLZPatternsExample1 http://www.zope.org/Members/sspickle/SQLZPatternsExample2
I have looked at them, in fact these examples turned me off from ZPatterns. I read their detailed description in Steve's book ("Zope: WAD&CM") and thought that I am missing something. Then I installed them and realized that I got it right. I just do not like the approach. In the introduction to ZPatterns Steve writes about aspects of a high-quality code: 1.simplicity 2.elegance 3.right choices of what to include into implementation 4.limited scope of object's responsibility
I agree with all four but (in my eyes) ZPatterns do not fit any of the above criteria. It would be interesting to cleanly rewrite the DumbZPatternsExample without ZPatterns and compare.
I had some reservations in mentioning the examples above - it again does to much to absorb when you are looking at it for the first time. I'm tempted to ask you why you think ZPatterns does not hold to the criteria above (because I still think it does) but I know how annoyed I was with the amount of time I had to spend to just get my head around my first ZPatterns app. With the help of mailing list I persisted. In hindsight, documentation could have solved this. In essence a ZPatterns app consists of your classes, Specialists that organises your app around object interfaces and class-level services and finally Racks which are the data managers that talk to your database. What is wrong with a design like this? I'm definately not a ZPatterns evangelist, but this is my grub: In the last month or so I noticed all kinds of Zope forum products seeing the light, mainly because people seem to have different storage requirements. If we had a Squisdot that incorporated a framework that proparly delegated storage decisions, plus CMF skins then more community effort could have been directed at the same product.
I also wonder if TransWarp/PEAK is mature enough to implement the intricate relationships between Doers, Deliverables, and ToDos. It should be - TransWarp mailing list is busy with selecting the package name and logo. ;)
Btw, PEAK incorporates a lot of the design ideas found in ZPatterns. PEAK storage depends on ZODB4 and python 2.2 metaclasses so it will probably only be usable with Zope 3.
We've been using ZPatterns extensively in a number of apps and it has given us a lot of joy. It is the best framework Zope _currently_ has for data abstraction and it is really not that complicated - it's just missing some documentation. In the available docs to much is said about what it can do for you and very little about how to do the simple things - one just have to know what pieces to wire together. (Maybe I need to write a howto if anybody is interested) We have extended ZPatterns in a number a ways to make life really really easy ............... We'll probably release the above in a week or two if there's any interest ;-)
I agree that ZPatterns is the "best framework Zope _currently_ has for data abstraction". As a new Zope user I think it's pretty sad. Maybe I am wrong - it would be great to see your add-ons (esp. skinnable solution) and maybe some better examples of ZPatterns usage.
If you keep an open mind for a little while longer I'll try to finish a howto with an example this week. If it still fails your immediate expectations, then we'll just have to wait ... -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za