At 12:53 PM 5/18/00 +0400, Jephte CLAIN wrote:
"Phillip J. Eby" a écrit :
When created, Racks create some default Attribute and Sheet providers. These objects are used by Rackmountables to access data which is not stored directly in the rackmountable.
Indeed, attribute and sheets are not stored in the rackmountable. Where are they stored then? in the specialist? in the rack? reading the code does not help to answer that question.
They are stored wherever the SheetProvider or AttributeProvider specifies. That is the point of having AttributeProviders and SheetProviders - to make it possible to put things in different places without application-level code needing to know where/how they are stored.
say I have in MyItem.py:
class MyItem(RackMountable, Item): "" meta_type = 'My Item'
def __init__(self, id): self.id = id self.i = 0 self.s = ''
and in __init__.py, MyItem is registered as a z base class
i and s are properties my objects are going to store. I would like to use MyItem objects until I am ready to move the data into an SQL database, where i and s will be columns in a table.
The AttributeProvider (that my rack have by default) raise an exception in MyItem.__init__ because i and s do not exist (indeed, I want to create them in the instance!)
Could you give the traceback? I think it is more likely your __init__ is failing because you are setting self.id. You should not set self.id directly in your __init__ method, you should call RackMountable's __init__ method like this: def __init__(self,id): RackMountable.__init__(self,id) self.i = 0 self.s = '' Or, better yet, don't define an __init__ method at all, and set the default values for i and s in your class itself. As a general rule, RackMountables should not redefine the __init__ method. (And yes, I'm going to add that rule to the docstrings right now...)
Also, say I want to add the OFS.ProperyManager.PropertyManager mixin class to MyItem to manage my properties through the standard interface. Will it clash with the sheet provider?
No. RackMountables can be PropertyManagers. The attributes will be handled by the AttributeProviders.
I'm not interested in the ZPatterns framework to allow my customers to customize the data sources or the collaborators. I'm interested in it because I want to develop code that is independant of the data sources. I want to store some data in the ZODB (because they are python list and dict, or because it is easier for me to use Zope objects until I move to a SQL database), and some of them in an SQL database (because they might be used by externals applications), but still want to have a common interface to the data.
The default AttributeProviders for a Rack are of two kinds: an "acquired" provider and a "persistent internal" provider. The "persistent internal" provider simply stores attributes in the object itself whenever you set them. i.e., it assumes that the object is stored in the ZODB, so setting an attribute will cause it to be stored. In effect, it's as though you just had a normal ZODB object. The "acquired" provider allows you to share AttributeProviders between Racks in a Specialist. If you add AttributeProviders to the Specialist, the "acquired" provider will detect this and make the appropriate attributes available in the Rack. Both of these providers can be removed or reconfigured; by default they are set up to use all available providers from the Specialist, and to allow any attribute to be set in a rack-mounted object. As other providers become available, such as SQLAttributeProvider or LDAPAttributeProvider (which Ty is tinkering with at the moment), I think this will all begin to make a bit more sense.