[Zope-PTK] content states

[Phillip J. Eby]

I would suggest that we make the convention even simpler.  How about just
having a method called "workflow_states" which returns a list of keywords
for cataloging, and leave its implementation subject to being overridden by
the implementor of a class?  Its default implementation can be to look at a
"state_sheets" attribute containing the names of the sheets which contain
state flags.  The keywords can then be rendered as something like:

sheetname.propertyname-value

Or whatever floats the implementor's boat.  Anyway, your implementation is
now done.  Complete.  Finit.  An object can now index as many states from
as many sheets representing as many processes as are desired.  Thus, an
object can participate in (say) both a content review process and an
editorial process, where the state sheets have different permissions and
are updated by different sets of methods.  *And*, if somebody needs a
different way of specifying workflow flags, they need only override the
workflow_states method to include their special flags as well.

I don't like having a "states" propertysheet, btw.  It's too generic of a
name, IMHO.  The sheet(s) should be named according to the actual workflow
taking place, so for content review it should be something like
"reviewing_checklist", which is crystal clear as to what it's for.  Want to
change the review process?  It should be clear that the first thing that
developer needs to do is change the reviewing_checklist definition for that
content type.  Similarly, member objects might have a
registration_checklist, and as your example mentioned, messages might have
email_flags.

By the way, if one uses a ZPatterns approach in building a Portal, one can
now cleanly build "Reviewing" and "Registration" specialists which get
their contents by asking the portal catalog for items based on
reviewing_checklist items and registration_checklist items...  Just a
thought.  :)


At 11:09 PM 7/19/00 +0100, Steve Alexander wrote:
>
>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
>