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.