[Zope-PTK] Member Publishing

Michael Bernstein webmaven@lvcm.com
Thu, 14 Dec 2000 09:42:16 -0800


Renato De Giovanni wrote:
> 
> > The transitions table of the state-machine screen should be
> > dropped, and transitions out of a state should be added from
> > within that state's edit screen.
> 
> Maybe we can have transition tables in both places? I like the possibility to have
> the whole picture of a workflow in only one interface (if we can't have those
> beautiful graphic representations with circles and arrows, let us keep at least the
> "global view").

Mmm, I supopose it wouldn't hurt anything, but I would
prefer to reinforce the notion that Transitions 'belonged'
to their originating states.

> > the main state-machine screen needs a multiple select input
> > field that lists all acquired roles. The selected roles
> > appear in the state and transition edit screens, the
> > unselected ones do not.
> 
> Ok, a kind role filter.

Yes.

> > I don't think that a special interface needs to be built for
> > sub-state-machines. It should be sufficient to create a
> > state-machine with the same id as a state either in the same
> > folder or somewhere below the folder containing the
> > state-machine object, and let acquisition do the rest of the
> > heavy lifting.
> 
> You guys really like the idea of sub-workflows... Well, nothing against them, I just
> don't see where they'll be essential. In case of implementing this feature, Michael's
> idea above seems very interesting.

As an example of where sub-workflows are useful, consider a
publishing company that has a unified proccess for
publishing books, and has defined states for receiving
manuscripts, reading and reviewing them, passing them along
to an editor, etc.

Further, let's say that this publisher publishes many
different kinds of books, so that the fact-checking phase
(for example) is different for technical books and for
biographies.

With sub-workflows, not only is it easier to deal with the
overall workflow at a different level from the fact-checking
workflow, but the sub-workflow is easy to overide when
neccessary, without having to overide the workflow as a
whole.

HTH,

Michael Bernstein.