[Zope] Data-Aware Folder

[Igor Elbert]

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