[Zope-PTK] content states

[Steve Alexander]

Dennis Nichols wrote:
> 
> (in my mind...)
> Flags imply non-exclusive settings
> Steps imply a linear succession of states
> States imply a non-linear (probably) partially interconnected set of, er,
> states
> 
> "States" seemed right but I haven't done ZPatterns yet.

I've thought about this a little more.

If we're going for low coupling and high reuse, I think having the
states on a propertysheet is the way to go. (Thanks Phillip.)

However, the way that the states are represented in that propertysheet
should be as generic as possible -- the workflow system that these
objects-with-propertysheets are used in gets to say what kind of thing
goes in each of the "slots" on the propertysheet.

As for what to call the fields... well, I think something generic and
meaningful would be good. In some systems, you think of states having
substates. Both states and substates can be collectively called
"states".
Some workflow systems will use Steps, and some will use Flags. (For
example, an email system will use Flags). Personally, I'm not too
bothered about the naming. I'd like for it not to be tied unnecessarily
to a particular style of workflow system, though.


Here's what I think we need -- a suggestion for an implementation, and a
set of conventions.

The intent is that if business objects follow these conventions, then
they will work with workflow systems designed to these conventions.

* Well-known name for the standard "states" propertysheet. (I'll go with
"states" for now. Let's discuss a good name for it.)

* Convention for allowed characters and length of state identifiers and
so forth. This must work with KeywordIndexes in a ZCatalog.

* Interface / Mix-in class that presents a view of the "states"
propertysheet(s) suitable for indexing with a KeywordIndex in a
ZCatalog.


Propertysheet called "states":

  * Stores the states that have no namespace.

  * Has a field to indicate the names of any other states-holding
propertysheets. The names of these other propertysheets are a sort of
"namespace". The idea of multiple propertysheets is that different
workflow systems or state-based systems can be integrated without
treading on eachother's toes. We can also have different permissions on
different propertysheets.



Example, with no particular meaning, just intended to illustrate the
pattern of the thing:

Object of type Message has two propertysheets; "state" and "email_state"

Propertysheet state:

  List of other state propertysheets: email_state

  Review: content_approved

  Cost: waiting_for_approval

Propertysheet email_state:

  read: yes

  replied: no

  flagged: no

  new: no



I should probably set up a Wiki for this, as it's got to the stage where
there are good ideas floating around, and would be good to capture them.

However, I've just returned from a rehearsal, and I need to sleep :-)
If no-one else has set up a Wiki by tomorrow morning, I'll do it then,
fill it with salient points from the discussion so far, and post a link
to the list.

I need simple workflow stuff soon for a particular project, but it would
also be nice to lay some groundwork that will fit into more ambitious
stuff later.

--
Steve Alexander
Software Engineer
Cat-Box limited
http://www.cat-box.net