On Tue, 2002-08-13 at 21:05, Igor Elbert wrote:
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:
My intent is simply that the people using ZPatterns should at least try to write up best practices and bring forth some documentation that can help a newcomer. With that one can at least make an informed choice without needing to bump your head against concepts that are not familiar to you. I stirred, because I wanted to know if I'll be wasting my time (which I don't have a lot of) - evidently there is enough interest.
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.
The example is meant to illustrate how to wire different parts of a ZPatterns app together - not to be taken as literally the best way to write a task scheduling app.
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 think this point of view is fundamentally different from most Product developers, not only from the ZPatterns way of doing things. Product developers have users and 3rd party developers in mind and see the ZODB as a point of collaboration and customisation. I don't think that you can hope to easily maintain a product that is basically a export of a couple of folders and methods that people import and customise locally.
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.
But once you've figured it out one stops jumping around ;-)
Now I need to write some data access methods.
I don't - I wrote some extensions that generate SQL based on the schema of my class and only customise them if needed. If your app has a lot of classes and you have to write select/insert/update/delete queries for all of them this saves a lot of time.
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.
In ZPatterns the properties of a single class can be populated from multiple datasources (LDAP, SQL, XML), properties on one class can be computed from that of another class and you get fine grained event handling. The point of ZPatterns is not to replace your SQL methods but to keep the layer that talks to whatever storage you opt for, separate from your application logic and this is just one of the benefits. Some people use it only for its fine-grained event management and collaboration services. I hope to have some documentation ready soon, and if you still find it unsatisfactory then at least you made an informed choice. -- Roché Compaan Upfront Systems http://www.upfrontsystems.co.za