[Zope-PTK] content states

[Phillip J. Eby]

At 11:41 PM 7/18/00 +0100, Steve Alexander wrote:
>Steve Alexander wrote:
>> 
>> Steve Alexander wrote:
>> >
>> > Portal Content with Multiple States at once
>> > -------------------------------------------
>> 
>> <narrative deleted>
>> 
>> Ok... it is all implemented (after some great fun with __setstate__ and
>> ComputedAttributes).
>> 
>> It works, and with minimal changes to the PTK. Tomorrow, I'll grab the
>> latest CVS, and produce a patch for it.
>
>I've put this off for a day or so, as I want to do it properly with an
>interface and some documentation.
>

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 realize that
this is a fine distinction, but there are times when you will want to deal
with a workflow in terms of states, where the transition between states is
based on some combination of steps having been completed.  From your
original example, an object having passed all content checking steps would
indicate an overall state transition.  One way of looking at this is
parallel steps vs. serial states.

Second, as far as the interface is concerned, it seems to me there is no
real advantage gained by creating a specialized interface as opposed to
using a property sheet or property sheets.  All you need to do is have a
method on the object that can create a keyword list from the propertysheets
so that you can catalog them.  Then you don't need a PersistentMapping or a
special interface, and if you use ZPatterns you also have the ability to
make those attributes live in whatever database you want or be computed
from other attributes.

Among the reason I suggest this, is that the idea of manipulating arbitrary
state flags gives me the heebie jeebies from a data-integrity perspective.
Defining the flags as properties gives you a place where you can attempt
type-checking, etc., and whether they are single or multi-valued, etc.  You
can even easily have drop-downs for the allowed states.

Anyway...  perhaps you could define a standard property sheet name
("review_checklist", perhaps?) for the content states, and then have the
keyword method simply generate one state flag per property in that property
sheet.  Portal authors could then redefine the sheet to suit their portal's
workflow, while still taking advantage of the keyword cataloging that you
were implementing this to drive.  And, to top it all off, you get the
benefit of only having to set the permissions on the propertysheet in order
to drive all of the security behavior...