RE: [Zope-dev] RE: [Zope] ZPatterns Question
At 01:57 PM 8/8/00 +0200, RC Compaan wrote:
I've added a propertysheet called "properties" to my ZClass and i notice there is Persistent Sheetprovider under the default rack already. The Sheetprovider has properties Sheet_Names and Sheet_Namespaces. I guess Sheet_Names should refer to the sheetname i created for my ZClass??? but how do Sheet_Namespaces come into play.
Actually, neither relates. Property sheets created on ZClasses always have their data stored in attributes of the object itself, so if you want to control those property sheets you would not use a sheet provider at all. Sheet providers are only used to provide property sheets whose data is stored external to the object.
Oh ok, this divide clears it up a bit. I somehow imagined that an object's properties are always stored inside the object and that Providers are the managers of those properties.
The Specialist does not talk to the sheet provider. The Specialist asks its racks for an object. The Rack which "retrieves" the object tells the object that it belongs to the rack and should ask the rack for anything it needs. When the object needs a property sheet or attribute or whatever, it asks the rack to give it a list of relevant providers for that attribute/sheet/whatever. It then walks the list asking those providers if they can perform the function it desires. If none of the providers are successful, it performs a default behavior (such as raising an AttributeError to indicate the attribute does not exist). This general pattern is followed for almost anything that can be delegated from a skin to a provider.
I considered the scenario where attributes are stored external to the object according to the filing clerk analogy on the wiki: The Specialist (filing clerk) asks its racks (filing cabinet) for an object (dental records). The rack (filing cabinet) tells the object (the dental records) that it belongs to the rack AND that the object should ask the rack for anything it needs. Why would the object "need" anything. Is it not the specialist with the "need"? If object data is stored external to the dataskin object does the dataskin only implement behaviour? I find it difficult to understand because I associate Dataskin with Storage. If object data is stored externally is it stored in Persistent Property Sheets? How does one define properties for Persistent Property Sheets? Roché
At 10:28 AM 8/10/00 +0200, RC Compaan wrote:
Oh ok, this divide clears it up a bit. I somehow imagined that an object's properties are always stored inside the object and that Providers are the managers of those properties.
I am finding that most people outside of Digital Creations aren't aware that there's any other kind of property sheet besides the kind that stores its data in attributes. :(
The Specialist (filing clerk) asks its racks (filing cabinet) for an object (dental records). The rack (filing cabinet) tells the object (the dental records) that it belongs to the rack AND that the object should ask the rack for anything it needs.
Why would the object "need" anything. Is it not the specialist with the "need"?
If object data is stored external to the dataskin object does the dataskin only implement behaviour? I find it difficult to understand because I associate Dataskin with Storage.
DataSkins do not implement storage; the whole point of a DataSkin is that it is storage-neutral. It is a behavioral "skin" which can be wrapped over other objects which actually implement behavior. It's a rather sophisticated variant of the GOF "Strategy" pattern, where an object delegates the choice of algorithm to another object.
If object data is stored externally is it stored in Persistent Property Sheets?
Well, that's one way to do it, and the only way implemented for you in ZPatterns currently. If you want to do it another way (e.g. SQL), you'll have to write your own sheet provider.
How does one define properties for Persistent Property Sheets?
By calling the standard propertysheet methods to manipulate their properties from code, e.g. manage_editProperties and the like.
participants (2)
-
Phillip J. Eby -
RC Compaan