[Zope-PTK] content states

[Phillip J. Eby]

At 05:59 PM 7/19/00 +0100, Steve Alexander wrote:
>"Phillip J. Eby" wrote:
>> 
>> I realize I'm coming into this a little late, but I needed to do some
>> thinking about this concept and how it fits with ZPatterns and SWARM.
>> Anyway, here were my thoughts on the concept and interface...
>> 
>> First, I would like to suggest calling these things "flags" or "steps"
>> instead of "states", as they actually designate the status of steps within
>> a workflow, rather than the overall state of the workflow.
>
>I'm happy with either naming. With calling them "states" I had a picture
>in my mind of a particular kind of state-transition diagram where you
>can simplify things by having two state-spaces in parallel. I'll try and
>dig out a reference if anyone's interested.

You're probably thinking of Harel's statecharts, and it's a useful concept
in general.  For the SWARM model Ty and I were working on, however, we
decided we would implement such parallel spaces as subobjects,
subprocesses, property sheets, or other 'seperate' objects.  This was
because trying to deal with parallel states of one object leads to all
kinds of headaches if you want state-specific versions of methods and the
like.  It's much cleaner if each "object" has only one true "state", even
though it might have many condition or step flags, and states might have
sub-states.  (In the SWARM model, a "state" is a hierarchical path like
Unapproved.Submitted, Unapproved.Reviewing, Approved.NotCopied,
Approved.CopiedToPublicArea, and so on.)

Of course, this is all a matter of design preferences, as there are as many
ways to design a workflow abstraction as there are workflow products out
there!  And what's appropriate for the SWARM model doesn't necessarily
apply to the PTK, although I suspect the PTK model is probably only going
to need a subset of SWARM's requirements, so making SWARM a superset of PTK
or PTK a subset of SWARM might be helpful for the community at large.