[Zope-dev] a simple example of the ZPatterns frame work

[Phillip J. Eby]

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.