[Zope-CMF] Re: A better CMFworkflow

[Ulrich Eck]

hi shane

> I encourage you to try out the DCWorkflow product.  Although it's still
> in its infancy, it provides a good way to implement everything you
> listed.  It is not shipped with CMF yet.  It was developed based on
> PTK/CMF community feedback that was remarkably similar to yours.
>

I have thought a lot about the state-transition-machine you used
for the DCWorkflow and you're right .. most of the scenarios
could be implemented using your Product.

However I'm still struggling with these questions:

- To clearly separate different (hierarchical) workflows i need lots of new
  PortalTypes (those main job is to define some workflow-relevat parts)
  After modelling a larger project into the DCWorkflow I'll have probably
  lots of objects which need to be stored somewhere (where ??) and may
  confuse users .. any suggestions on this ??

- some of the features in the dc-workflow:

  How does Triggertype: Initiated by WorkflowMethod work ?? is this
  transition triggered when the script is called or is this just a
definition
  that the script should trigger this transition??

  What's the intend of  Guard/Expression .. is this an expression that
  controls the transition to happen or not and if .. what type of
expression:
  regex or python (and what namespace)



> The feature of binding types to workflow definitions is *specifically*
> designed to make sub-workflows and multiple simultaneous workflows
> possible... and maybe even easy.
>
I can still not relly figure out how this should work, if e.g. something
depends
on some other part of the workflow to be finished, if these parts in
different
workflows (A document and a corresponding news-item for example, where
the news-item can only or must be created when the Document is published)

As far as I understood what there happens is: Every PortalObject is part
of is own workflow while its lifetime. they're all executed parallel and
there
is no obvious mechanism to syncronize their behaviour.

Did I get this right ??

> If you disagree, however, just make your own portal_workflow tool.  You
> don't even have to change the CMF source.  The binding of type to
> workflow is only an assumption that the default portal_workflow makes
> and nothing else in CMF depends on it.  Really!
>

This will be the last thing I'll start .. I'm thinking of some combination
of
the "ObjectWorkflow" (yours :) and an addition that could be called
portal_groupworkflow which is better in handling multi-user/multi-object
workflow that is activity/task-centric .. what do you think about that?

cheers
Ulrich Eck