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
something else we can change it using other methods in our racks or
> >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"
> >is this right so far ??
> Pretty much, although I'm not sure why you want to pick by meta type,
> 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,
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 = (
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
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
Is this the right design for an application i want to build ??
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -