At 07:23 PM 12/12/00 +0100, Ulrich Eck wrote:
>I can deal arround that if i reget the DSO from the specialist in every
>function which deals with DSO's.
This is the correct way to do it if you are using Specialists rather than
Folder w/Customization Support.
>is there a better way to
>a) tell my TransactionManager that my attribute "ds_object" is not pickeable
>(e.g. call it _v_ds_object)
> and how to know if zope is restarted ?!?!?
>b) store this object persistantly in my TO without showing it in the
>folder-structure but behave like a DSO
> set/get attributes through Skinscripts
Yes. Use a Folder w/Customization Support above your transactions. When
you access TO.ds_object, the DataSkin will search for a DataManager and
find one in the FwCS, assuming you've configured one.
Note that this is mutually exlcusive to using Specialists to store the
DataSkins. In the FwCS approach, you configure Customizers for each
meta_type of objects you'll be dealing with. You can then give them
SkinScript, etc. to configure behaviors. Also, this approach requires use
of the ZODB to store at least the "shell" (class reference and ID) of each
DataSkin. But since your application is ZODB-dependent already, this is
not an issue.
Personally, I'd suggest that if you want to take advantage of ZPatterns'
database independence, you should instead restructure your app so that your
TO's are themselves DataSkins, stored in a Specialist. Right now, you have
a very heavy dependence on the ZODB.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -