[Zope] Data-Aware Folder

[Roché Compaan]

On Tue, 2002-08-13 at 21:05, Igor Elbert wrote:
> Roché,
> 
> I was re-writing zPatterns example without zPatterns when I saw your angr=
y
> 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 noi=
se
> on the Internet (mail-lists, including the one dedicated to zPatterns) fe=
w
> people use it. Well, dogs do not always eat the dog food. On the other ha=
nd
> 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 Product=
s
> 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