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. The "name" refers to sheet names, yes, although again these are not ones created on the ZClass, which will be handled by the ZClass. The "namespaces" refers to the XML namespaces of the property sheets, which is a WebDAV thing. In the WebDAV protocol, "property sets" are added/changed using URLs as XML namespaces. So you could have a property sheet whose XML namespace is "http://www.zope.org/PTK/MemberProperties" and whose name is just "MemberProperties" or "MemberInfo" or something else altogether. ZPatterns supports WebDAV, and WebDAV requires the ability to add arbitrary property sets with arbitrary properties to an object. Also, the XML namespaces concept can be useful as a way of avoiding name collisions between frameworks.
From the IRC_Chatlog: "Call "getItem(key)" to retrieve an item from the Specialist, and "newItem(key)" to create a new item in the specialist."
Does this imply that I can simply call "newItem(key)" from a dtml-method inside the specialist to create a new instance of my object?
Yes.
I think I understand ZPattern architecture somewhat but get lost on the implementation side, particularly at that place where attributes are retrieved from storage or more clearly how a specialist(datamanager) links up/communicates with a sheetprovider (data-plugin) and how the sheetprovider in turn communicates with the rack and how the rack retrieves from storage (dataskin).
A very simple outline like this would help me a lot, eg: Specialist to Sheetprovider (handled in IDE - add a SheetProvider under Plugins) Sheetprovider to rack (handled in IDE - select Storage Class under rack) Rack to Dataskin (????) Dataskin to physical storage (????)
Roché
PS: I would be more than willing to document my enlightenment in a howto
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. When DataSkins are used outside a rack, the process is similar, except that the DataSkin itself notices it is being retrieved from somewhere and has not been told it belongs to a rack, so it searches its acquisition path asking for a Customizer. Once found, it then uses the Customizer in the same way as it would have used the Rack (i.e. to ask for lists of providers that might be useful for performing tasks it needs done).