[Zope-PTK] ZPatterns and DatabaseAPI (was Getting it all
to work ;-)
Phillip J. Eby
Tue, 04 Jul 2000 01:37:18 -0500
At 09:17 AM 7/1/00 -0400, Shane Hathaway wrote:
>I have been pondering whether it might be beneficial to make use of the
>DatabaseAPI product to solve the interface problem. Not too many people
>know about it because it was released about the same time as ZPatterns,
>which got a lot of attention. I wrote it with similar goals in mind.
Actually, you released first, as I recall, because I downloaded DatabaseAPI
in the hopes that you had already done what I needed for the database parts
of ZPatterns. Unfortunately, I had the same problem with your product as
others have with mine - i.e., lack of good conceptual and practical
introductions to it.
Also, its goals (from what I could tell) were somewhat different than mine;
I wanted to make object manipulation transparent across multiple databases,
and thoroughly eradicate all database knowledge from the problem-domain
code to the extent that there's no way to tell if a database is even
involved. You seemed to me to be addressing implementation-level
abstractions, which is a different but equally valid concern.
It is possible, however, that I have misunderstood what your system does,
and I will take another look at it in the near future to see if there's
anything worth stealing. :) From reading your description in this e-mail,
it sounds like your API concept may be addressing a similar problem to what
Specialists are intended to address, in which case there may be some
benefit to some interbreeding between the systems.
>DatabaseAPI does not make any assumptions about the structure of the
>data, while ZPatterns assumes the data is stored in indexed database
That's not correct, actually. Each attribute or propertysheet of a
DataSkin may be "stored" anywhere, including "virtually" (i.e. computed).
One could implement a Provider/Trigger pair that made attributes that were
"stored" in X10 such that a Lamp object could tell you its dimming setting,
or change it, by manipulating that attribute (which would cause X10
commands to be sent to query or change the real lamp's dimming status).
The Lamp object would simply need some attribute to tell the Provider
and/or Trigger what the house code and unit code of the X10 lamp unit was.
Note that this attribute wouldn't even need to be the object's 'id'
attribute; it could be an attribute stored in the ZODB or in an SQL
database, or computed from some other attribute, which in turn could be
stored or computed in an arbitrary way, and so on.