[Zope-CMF] workflows what are they and how to use them

Kent Polk kent@goathill.org
2 Aug 2001 19:31:28 GMT


On 26 Jul 2001 13:50:01 -0500, albert boulanger wrote:
> 
> 
>    > Many workflow systems indicate the states in a state engine explicitly
>    > and the content objects are only related to the state object through
>    > say a list.  The content object also points to the state
>    > object(s). Thus a content object can be in mutiple states in mutiple
>    > workflows and a workflow can be pushing mutiple content objects.
> 
>    Interesting.  Would the state object be a child of the content object, a
>    peer, or completely disjoint?
> 
> I would favor disjoint, and this was the point of the push example
> below. I was trying to make a case of workflow were the associated
> content (ie the push) was far from being the normally-thought-of-stuff
> that the CMF workflow is working with now to stimulate thinking.
> 
>    Note that DCWorkflow does allow an object to be in multiple states in
>    multiple workflows (but one state per workflow).  A workflow can also
>    govern multiple content objects if the content objects are children of the
>    object to which the workflow applies.
> 
> That's good.
> 
>    > Personally I would like to see a workflow system for Zope where the
>    > objects being pushed are any kind of thing including "push" activities
>    > like "ET phone home" on say a pager.
> 
>    I mean this in the best way, but what prevents you from doing that today?
>    How would you do it differently from writing a Script (Python) that sends
>    mail?
> 
> Yeah. I would then use that script as an attached action to the
> explicit workflow state. I was not really bringing this up about how
> to execute the action but to use it as an example of associated
> actions a workflow state may have attached to it.

One question I have regarding how a project-centric workflow would
store state information, etc is related to how the created by the
Workflow are located... Dowe use the Workflow to locate items, or
the Catalog, or could the Workflow use the Catalog?

My original thoughts (about a year ago) on this were that there
would have to be a project folder of some sort that acted as the
state-machine repository and could be use to catalog the pertinent
metadata.  However, the real world doesn't work that way and as I
began to try to devise a Project Container, I kept backing up,
futher and further to handle the creation and maintenance of
necessary inputs for metadata that I became completely bogged down
in preconditions that I couldn't really maintain.

Sometimes things really do have to appear out of thin air...

  * and * be able to contribute to the workflow.

  * and * be able to have forms generated on the fly to deal with
  them...

Speaking of, Ulrich needs to show off his new CMFFormsTool RSN, as
I think it could prove to be a very nice and and important addition
to a CMF site. It incorporates PageTemplates and Formulator to let
you describe how to automatically build a form based on the property
names it finds and apply them to specific CMF Types... Very important
for where I think we are headed with this.  (and really cool) And
I hope he doesn't knock my block off for giving it away...

(And why we needed to have CMFDecor fixed for folder_contents. :^)
Thanks Much!)

Back to Workflow, instead of trying to figure out how to accomplish
project-centric workflow (better name - as opposed to Document-Centric?)
What are we attempting to accomplish in terms of building views of
the current Workflow status and possible actions? This will largely
determine how to structure the workflow data.

So, how to retrieve the workflow data (metadata such as state
condition, and items created and managed by the workflow) in a
CMF-compatible fashion?