[Zope-dev] RE: [Zope] ZPatterns Question

[Phillip J. Eby]

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