[Zope-PTK] ZPatterns and DatabaseAPI (was Getting it allto work ;-)

[Shane Hathaway]

"Phillip J. Eby" wrote:
> 
> 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.

Perhaps.  It did come with a demo.

> 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.

Actually, A "DatabaseAPI" would be more properly named simply
"Interface", although there was some special manipulation in there that
made things simpler when dealing with databases.

I have been trying to deconstruct the ideas that I came up with in
developing DatabaseAPI and ACLManager.  Development of the following
would make DatabaseAPI irrelevant (a strange goal, I know, but the idea
is to make Zope more integrated, not less):

1. An object type called "Interface method", which would be addable to
ZClass definitions.  Thus we could write ZClass-based interfaces.

2. A change in the ZClass UI that would make it easy to write method
implementations.  The developer would just subclass the interface and
instantly know what methods need to be implemented.  Note that
interfaces could be written in filesystem-based Python also.

3. Standardization in method invocation semantics.  I struggled a lot
with the fact that DTML Methods are invoked one way while Python
Methods another.  I found a way to force DTML methods into obedience.
:-)

Development of the following would make ACLManager irrelevant:

1. Make LoginManager stable.

2. Rule-based local roles, which may take the form of "groups". 
ACLManager could do something like this, but the idea that was brought
out today would be much more integrated.

3. Integrate the code for persistent cookies into LoginManager.  It
would be some form of a plug-in.  My code was able to share cookies
between distributed servers and restore sessions when Zope is
restarted.

When I wrote the two products, I didn't fully grasp the workings of
acquisition and proxy roles so there is some unnecessary baggage in
there.

> >DatabaseAPI does not make any assumptions about the structure of the
> >data, while ZPatterns assumes the data is stored in indexed database
> >tables.
> 
> 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.

Okay, you're probably right, but the way one would approach this is
entirely unclear.  Let's make this a multiple-choice quiz. :-)

To implement this scenario, you should start by creating:
A. An X10AttributeProvider.
B. An X10Specialist.
C. An X10SheetProvider.
D. An X10DataSkin.
E. An X10Trigger.
F. Other (specify)

You will need to create a Specialist called House and put a Rack in
it.  You'll have to create an X10Device ZClass which is derived from
DataSkin.  The X10Device objects, which have the properties "title",
"house_code", and "device_number", will be stored in the rack.
A. True.
B. Not quite (specify)

To use a rack, objects must have an ID.  A good choice of ID's might be
the house code and device number concatenated together.  Of course, if
you have to change house codes because of a conflict with your
neighbor, you have to change all the ID's.
A. True.
B. False.

Then you'll have to write your own UI and storage mechanism so you can
store and manipulate these things in the rack.  This is what was
required to use DatabaseAPI.
A. True.
B. Not quite (specify)

Shane