ZPatterns: persistant objects hold DataSkin-Items -> KeyError: _v_dm_
hi out there, i use zpatterns/specialists for a Network-Documentation Tool. I'm writing a Product which controls the relations between specialists and manages multible actions (edit/new/delete) for ZPatterns DataSkinObjects (DSO). I have a Product-Instance of ZTWM (ZTransactionWorkflowManager) in my application root which is a Folder by itself and holds as folder-objects its 'Transactions' (in this case a Transaction starts at the first edit-action and lasts til the last submit of a form with valid entries - e.g finish transaction.) It behaves like a Wizard (PTK) with next/back/cancel/finish buttons and reads out the DataSkinPropertysheet for creating the edit/new forms on the fly. One can also define relations between the specialists an they are used to edit Foreign Keys. small painting here: \application-root --\<Person> (specialist for persons) --\<Komponent> (specialist for komponents) --\<ZTWM> (my TransactionWorkflowMangager - Folder) ---- \<1> (first transaction -Folder) -------\<1> (first transaction object - Folder) --------| ds_object (attribute which references the DSO) --------| more info on the current Transaction object -------\<2> (second Transaction object) --------| ds_object (attribute which references the DSO) --------| more info on the current Transaction object ----\<2> (second Transaction) ... so far about how it should work .. For each TransactionObject (TO) I save the Object I retrieved with "specialist.getItem(id) == DataSkinObject(DSO)" as attribute "ds_object" to the TransactionObject. After I restarted Zope and want to replay/finish a transaction, i get an KeyError, Value _v_dm_ the prefix _v_ stands for not pickeable (afaik) dm for datamanager ?!? ok .. i put a TO in the Transaction, get the actual DSO, call the transactionmanagers editor function and a form with correct values is displayed, i can edit this form and call the DSO manage_changeProperties method from the transactionmanager. when i don't finish a transaction and restart zope i still have my transactions with proper values saved in my TransactionManager - except the property "ds_object" wich was assigned to the DSO at TO-creation when i try to set/get an attribute i get the KeyError of "_v_dm " ... I can deal arround that if i reget the DSO from the specialist in every function which deals with DSO's. 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 ?!?!? 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 hope that i described clearly enough where my problem is ... thanks for your reply Ulrich Eck net-labs
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 ?!?!? 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.
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.
At 06:31 PM 12/13/00 +0100, Ulrich Eck wrote:
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.
Not to store your objects, no. You can still use Specialists to concentrate search methods, constructors, UI snippets, and the like. Typically, in that configuration some of your Specialists may contain (or be) ZCatalogs which index selected objects from your FwCS hierarchy.
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)
Not necessary. If you retrieve your DataSkin as an attribute of its container, the DataSkin __of__ method will automatically find and bind the DataManager (assuming you're not using some class that overrides __of__).
Do I need to implement methods like createItem/retrieveItem/_v_itemConstructor as well or how do i "get" my objects ??
Just retrieve the objects from their containers in the normal Zope way. Ditto for creation - use the standard way of constructing objects in an ObjectManager.
If I have an object whose metatype is handled via customizer/skinscript/sqlmethod it'll probably work managing attributes ..
Yes, it should. Likewise triggers, if you want to set up cataloging triggers.
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
Just use the normal Zope "add list" to create one manually, or call the appropriate constructors (e.g. SomeZClass.createInObjectManager()).
is there an example those newItem(<meta_type>,key) - getItem(<meta_type>,key) ??
You want examples? You forget, this is ZPatterns. ;) Seriously, look for examples of how to create an object by meta_type in a Zope ObjectManager.
Not necessary. If you retrieve your DataSkin as an attribute of its container, the DataSkin __of__ method will automatically find and bind the DataManager (assuming you're not using some class that overrides __of__).
ok i've gone all through the source searching for a method to get an object of a <meta-type> with <key> ... when I call FwCS.getOb(id) then i get back an object with ??meta-type?? if I have different Customizers all serving one meta-type ??? example: I Have a Customizer for an EventClass and another for LocationClass they're both stored in an database using an unique int as PrimaryKey when i call getOb(1) how should my FwCS know which one it should give back ??
Just retrieve the objects from their containers in the normal Zope way. Ditto for creation - use the standard way of constructing objects in an ObjectManager. Just use the normal Zope "add list" to create one manually, or call the appropriate constructors (e.g. SomeZClass.createInObjectManager()).
Yes, if i create an object and call FwCS._setObject(id,ob) the FwCS can choose the right place to store the object e.g. if properly configured using a Customizer with SSMethod
is there an example those newItem(<meta_type>,key) - getItem(<meta_type>,key) ??
You want examples? You forget, this is ZPatterns. ;) Seriously, look
for
examples of how to create an object by meta_type in a Zope ObjectManager.
just the one snippet of code which how to serve the problem i described .. thanks again for your appropriate help Ulrich Eck
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
Just use the normal Zope "add list" to create one manually, or call the appropriate constructors (e.g. SomeZClass.createInObjectManager()).
after a while I think I got it now. I use a FcWS as a Folder like usual in Zope and if i create an object of a type which is "customized" certain attributes will be set through the customizer. so for a database app that handles multiple tables it isnt useful to handle with a FwCS. First I thought there is the same "magic" as if i ..getItem() with a specialist .. in a FwCS Due to the Folders Rules, there can only by one object with the same id at a time in one FwCS .. I'll switch back to a Specialist which has many racks as data-providers which i can choose the right one with a method that has a "meta-type" parameter. is this right so far ?? Ulrich Eck
At 02:49 PM 12/14/00 +0100, Ulrich Eck wrote:
after a while I think I got it now.
I use a FcWS as a Folder like usual in Zope and if i create an object of a type which is "customized" certain attributes will be set through the customizer.
Yes.
so for a database app that handles multiple tables it isnt useful to handle with a FwCS.
Um, not necessarily. You can create regular Folders under the FwCS if you want to keep them seperate. You can even use BTreeFolders or other ObjectManagers, if you like. All that's required is that they support the ObjectManager protocol. So you can have a folder for each meta_type. Of course, the primary storage of the object has to be the ZODB.
First I thought there is the same "magic" as if i ..getItem() with a specialist .. in a FwCS
No. The FwCS is to allow more "traditional" Zope objects to blend in data from other sources, and/or to have trigger support.
Due to the Folders Rules, there can only by one object with the same id at a time in one FwCS ..
Yes. But you don't have to place the DataSkins directly under the FwCS, they can be any number of nesting levels below it.
I'll switch back to a Specialist which has many racks as data-providers which i can choose the right one with a method that has a "meta-type" parameter.
is this right so far ??
Pretty much, although I'm not sure why you want to pick by meta type, since one of the major reasons for having a Specialist is for the rest of the application not to know about specific meta types.
participants (3)
-
Phillip J. Eby -
Ulrich Eck -
weblabs