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: <Register a new Komponent> < add at least 1 Physical Port> <add for every Physical Port at Least One Logical 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