[Zope-PTK] Member Publishing

Kent Polk kent@goathill.org
14 Dec 2000 16:19:21 GMT


On 14 Dec 2000 09:15:00 -0600, Renato De Giovanni wrote:
>> Actually, I think that workflows should inherently implement
>> sub-workflows. That's how process are organized and how people
>> work. One could argue that with an adequately designed workflow
>> system, *everything*, including queries are sub-workflows. Not to
>> mention that many workflows *require* sub-workflows...
>>
>> As to whether a sub-workflow constitutes a sub-state, I'm not
>> exactly sure... :^)
>
>Hi Ken,
>
>Untill now I havenīt seen a real situation where states of an object/entity cannot be
>represented in only one workflow... I know that transitions in a workflow may
>sometimes trigger other transitions from other workflows - this may happen when
>different objects have a composition or dependency relation between them (for
>instance, after cancelling an order item the order itself may also be cancelled or
>not). But this is not a sub-workflow example.
>And I can imagine an object/entity participating on more than one independent
>workflow, although I never faced this situation.
>
>But sub-workflows... Maybe I'm wrong, but I see them as a mere grouping of
>states/transitions from a big workflow according to some criteria - in other words,
>sub-workflows would happen "inside" generic "super-states" (Am I right here?? Someone
>please correct me if I'm wrong).
>I'd like to see a real example where sub-workflows are really needed. Otherwise we'll
>be introducing unnecessary complexity to this issue.

Possibly we are not communicating well. :^)

How would you handle a case where a request to construct some object
required that a series of other objects be constructed, where each
of the subobjects to be constructed involved a QA feedback loop.
After all of the all of the subobjects were collected, analyzed
and approved, they were used to assemble the original object
requested.

Each sub-creator needs to know only about their little workflow.
The parent creator needs to know about the status of the main object
and all of the subobjects.

Sounds like sub-workflows to me. How would you do it without them?