[Zope-dev] ZPatterns: persistant objects hold DataSkin-Items -> KeyError: _v_dm_

[Ulrich Eck]

after one more day of source-code-reading i got that far:

When I want to use a Folder /w Customizer (FwCS) I cannot/don't need to use
Specialists.

i create a FwCS and put my 'Framework' in it.
if i want to access (get/new) an object handled by a customizer
i can ask FwCS._getDataManagerFor(client,default) for my datamanager (DM)

Do I need to implement methods like
createItem/retrieveItem/_v_itemConstructor as well
or how do i "get" my objects ??

If I have an object whose metatype is handled via
customizer/skinscript/sqlmethod it'll
probably work managing attributes ..

I'm searching for something that handles a newItem(<meta_type>,key) function
that is provided
from the FwCS who decides which object-type is created and gets those
attributes from the customizer

did I get this right so far ??

is there an example those newItem(<meta_type>,key) -
getItem(<meta_type>,key) ??


thanks
Ulrich Eck

> >
> >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 ?!?!?
> >or
> >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.