[Zope-CMF] CMF & OpenFlow integration

kent kent@goathill.org
4 Apr 2002 02:21:10 GMT


On 2 Apr 2002 08:55:00 -0600, Tres Seaver wrote:
> Wolfgang Klinger (mokka) wrote:
> 
>> has somebody used OpenFlow in the CMF?
>> are there any documents or other helpful hints for
>> OpenFlow integration?
> 
> OpenFlow is based on an "activity-based" workflow model;  CMF's
> workflows are "entity-based".  Resolving the gap was one of the
> goals of the "workflow sprint" in which I participated last month
> in Saarbruecken:
> 
>    <http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Workflow>
> 
> The main goal of the sprint was to identify the workflow architecture
> for Zope3, in a way which accomodates both models.

(pretending I know what I'm talking about)

As some of you know, Vincenzo spent several weeks recently working
with us to evaluate our workflow needs and to consider what it
might take to CMF-ify OpenFlow. Both of us learned quite a lot in
the process. Towards the end, Vincenzo had mostly drafted a set of
new use cases, process definitions, etc. for the needed changes to
OpenFlow and we are trying to determine how to implement them and
to move much of the duplicated machinery over to the CMF world.
Hopefully before long we will have something very interesting to
work with.

> For the CMF in the immediate term: it should be possible to use OpenFlow
> in conjunction with the CMF workflows, but not *as* a CMF workflow.
> Based on what I leared at the sprint, it may be possible at some
> point to integrate the two more directly.

I suspect that CMF workflow and OpenFlow are too disparate in Zope2
to integrate them. Even the current CMF actions box doesn't really
apply to activity-based workflow, though maybe it could be hacked
in. For the moment, an activity-based actions box could be appended
to the current one, but I'm not sure that such is really how one
should handle a task list for an activity-based workflow. I'd
certainly like to see it if possible, but I believe it doesn't
really fit in with how people handle such.

One can easily drop in an OpenFlow instance into a CMF site and
have it work. And the CMF offers many of advantages for OpenFlow
in building the applications controlled by the process definitions.
If you want to use the CMF authentication mechanism (most likely),
you will need to essentially mirror some of the role/user settings
though.

What we currently plan on doing for Zope2 is to move CMF functionality
and behavior underneath OpenFlow so it can take advantage of all
the good stuff that is already in the CMF and we hope to convince
the CMF OpenFlow and DCWorkflow to communicate with each other.

BTW, the CMF catalogger can be very handy in assisting workflow
applications which need to find objects created by the CMF in
conjunction with a workflow instance. While we need to have exposed
a little more status functionality for workflow applications, the
catalogger provides somewhat of a transport interface for certain
types of workflow manifolds.

One other large benefit of CMF-ifying OpenFlow would be that
applications will be able to use skins instead of having to attempt
to remember your workflow definitions context, to a large degree.
There is still a problem with maintaining context when you have
more than one process instance or process definition, and we are
still puzzling over a good way to maintain that.  Right now, if
you have just one set of process definitions that manage just one
set of process instances, the current OpenFlow dropped into a CMF
will likely do very well.