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
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
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) -
> >a) tell my TransactionManager that my attribute "ds_object" is not
> >(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
> TO's are themselves DataSkins, stored in a Specialist. Right now, you
> a very heavy dependence on the ZODB.
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -