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



_______________________________________________
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 )

Reply via email to