[Zope-dev] ZPatterns: Non-ZODB storage and Racks

[Phillip J. Eby]

At 10:45 AM 11/9/00 +0100, Rik Hoekstra wrote:
>[rh]I've been following this thread. This may be a bit of a newbie question,
>but it's been bugging me for a while. I see how I can store propertysheets
>in Racks using ZClasses and Skinscripts, but the propertysheet term suggests
>that there should always be an object that the properties are attached to.

Depends on what you mean by "attached".  One of the most annoying things
about Zope propertysheets is that there are two kinds.  ZPatterns
implements one of the kinds (WebDAV sheets), but not the one that most
people have encountered (the kind used in ZClasses).  Although WebDAV
sheets are associated with a particular object, they are objects in
themselves.  ZClass instance sheets are "virtual" and store all their data
in the associated object.

To do ZClass-style sheets in ZPatterns, all you need to do is implement the
attributes; the sheets can take care of themselves.  To do WebDAV-style
sheets in ZPatterns, you need a SheetProvider or you need to simulate
propertysheets using an attribute provider to make an attribute that is
actually another object, and which supports appropriate methods.


>Is that an actual ZODB object or is it the Specialist object that can
>'create' virtual objects on the fly?

Racks create "virtual" objects when set to "load by accessing attribute ___".


>[rh] If I read this right, this suggests that an object stored in a SQL
>database and 'masquerades' as a Zope object? Or does an object always have
>to exist in the ZODB (with it's own id that corresponds to the id in the RDB
>or knows how to retrieve it).
>In other words, does the ZPatterns framework need an 'anchor' in the ZODB to
>connect it's properties to, or can you create pure virtual objects, that
>retrieve all of their properties from a specialist, including the ID.

When set to store objects persistently, "real" Zope objects are made and
stored in the rack.  When set to load via an attribute, the rack creates a
dummy Zope object with its "id" attribute set appropriately, then tries to
access the specified attribute.  If the attribute exists (i.e., an
attribute provider succeeds in loading the data from the external data
source), then the object is considered to "exist" and can be returned.
This would be a "pure virtual object" in your question.


>If the last is the case, could someone give an example how to implement it.
>A very simple one would suffice I suppose (hope).

Roche's situation is an example, at least if he used the "name" attribute
as the load attribute, rather than the "id" attribute.