At 07:02 PM 6/3/00 +0800, Mike wrote:
>"Phillip J. Eby" wrote:
>> Two things.  1) WebDAV support requires the ability to add arbitrary
>> property sheets containing arbitrary data.  2) Propertysheets (especially
>> when used with XML namespace URL's) give a way of standardizing an
>> interface to common properties, without polluting an object's "main"
>> namespace.  This way, one can take an object that wasn't designed for a
>> certain purpose, and attach a propertysheet that serves as an adapter to
>> give it a different interface to its data.
>Just to be sure I understand this right. In my case this can mean one
>(person who manages product catalog) can once decide the products should
>contain also customer's feedbacks. He will need to add new propertysheet
>defining new properties and provide storage where those properties will
>be saved. Right?

That's correct.  If you have a "Persistent Sheet Provider" in the Rack that
supports the correct name/namespace (or uses a "*"), then any new sheet you
add will get saved in the Rack, as long as there isn't another provider
earlier in the list that supports that sheet.

This means that you can initially have that sheet be a plain ZODB sheet,
and later decide you want it in an SQL database.  You simply add an
SQL-based sheet provider set up to store that sheet, and put it in the
provider list ahead of the persistent sheet provider.  From now on, when
you add a sheet of that name/namespace, it will be stored in the SQL
database.  When you retrieve a sheet, it will come from SQL if it's there,
or the old ZODB if not.  And if you delete an object's sheet and re-add it,
it will be transferred to the SQL database.

>Would you be so generous please and suggest me how to handle other hard
>situation. My old catalog products were based on folders so they were
>able to contain data of any kind - images, tiny tables, etc. Will it be
>a big sin if I create product property called, for example,
>'associated_resource_id_list' and create 'universal' rack containing all
>that junk? Of course, every junk item will support certain protocol such
>as (__call__,index_html). (But how I will edit them?). Or should I
>create separate property sheets for every junk item type as they appear?
>Really, I'm in the big doubt.

If you use the option of storing your objects persistently in the rack, you
can subclass your DataSkins from ObjectManager or Folder, but you will have
to do a little work to get manage_afterAdd/beforeDelete working properly,
since their default implementation in the DataSkin class doesn't handle
sub-objects.  All of the standard attributes of a folder would then be
stored just like a regular folder; only the propertysheets and extra
attributes defined by providers on the rack would be inserted from other
data sources.

(By the way, you'll notice that I've been cc:ing my replies to the zope-dev
list; I'd appreciate it if you could send your questions there as well.  By
our having this conversation on the list, other people can benefit from it
as well.  Thanks.)

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to