Re: [Zope-dev] ZPatterns: persistant objects hold DataSkin-Items -> KeyError: _v_dm_
hi Philip ...
> >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.
>
>
this is not really what i plan to do ..
the main storage is the sql-database in this case .. if another application
needs
something else we can change it using other methods in our racks or
customizers.
> >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.
>
I renamed my Product now to ZWorkflowManager which is a bit clearer.
we want to develop pluggable parts for "big-multi-feature-app" like a
network-inventory/documentation tools as part of the hole.
in every part there are predefined Workflows
e.g. a network-doc-tool has a Workflow:
< add at least 1 Physical Port>
and so on ...
to ensure reusability of the hole process I want to support
several Metatype with my WorkflowManager which is
derived from a Specialist now.
these are for example
form-rendering, property-validation (with plugins) and
property-updates as well as creating new obects of
every supported type via on the fly generated Workflows
(defined through dependencies between Metatypes)
Right now i my ZWorkflowManager is derived from a Specialist.
It has Racks which hold every supported Metatype in a rack for it own.
Those can be generated with a widzard which creates a ZClass_for_Dataskin
all needed ZSQL-Method an a default-SkinScript for a DataBase Table
It has a PluginContainer for Validators which can e.g. validate a certain
ipaddress against lexical and logical rules. Every Plugin supports one
or more different check_types e.g. string :), ipaddress, subnet,
phone/faxnumber, ...
Therefor I would need an extension of the DataSkinAttributePropertySheet
which uses one more field in the _properties Dictionary and another
for label definition of on-the-fly generated forms e.g.
I_properties = (
{'id':'title','type':'string','mode':'w','check_type':'ipaddress','label':'I
P-Address'},
)
can i Extend a DataSkinAttributePropertySheet by extending its basic
attributes and modifying
its manage_workspace(..) method to support my extensions ??
The ZWorkflowManager can reender new/edit-forms, delete-screens, views and
search-forms/results
for every Meta_Type stored in a rack of itself. perhaps there will be
something like LinkToParentWorkflowManager :)
my ZWorkflowManager provides the functionality to analyse and validate all
metatypes attributes via check_types
and hopefully a fitting validator-method in the Validators PluginContainer.
The ApplicationIntegrator then can easily build different userscreens,
browse-methods with related Information
in the Specialist which serves a userinterface for the hole app in realation
to network-doc-stuff.
Is this the right design for an application i want to build ??
cya
Ulrich Eck
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns: persistant objects hold DataSkin-Items -> KeyError: _v_dm_
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns: persistant objects hold DataSkin-Items -> KeyError: _v_dm_
> > >I'm searching for something that handles a newItem(,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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns: persistant objects hold DataSkin-Items -> KeyError: _v_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__). > ok i've gone all through the source searching for a method to get an object of a with ... 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(,key) - > >getItem(,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 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns: persistant objects hold DataSkin-Items -> KeyError: _v_dm_
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(,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(,key) - >getItem(,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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns: persistant objects hold DataSkin-Items -> KeyError: _v_dm_
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(,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(,key) - getItem(,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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZPatterns: persistant objects hold DataSkin-Items -> KeyError: _v_dm_
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
