[Zope-PTK] content states

[Phillip J. Eby]

At 11:50 AM 7/20/00 +0100, Steve Alexander wrote:
>
>Right. Interestingly, this scheme allows a developer to implement a more
>complex way of doing things if they want to.

Right.  That was the idea - reducing exposure of implementation by way of a
simpler interface.


>Also, you suggestion above means that you can have complex state
>information in the propertysheet, so long as you provide an
>implementation of workflow_states() that simplifies it for use in a
>ZCatalog.

Exactly.  I saw the catalog keyword issue as being the problem you were
really trying to solve, so my proposal focused on that specific problem.
The structuring of the data to be put in the keyword index is irrelevant to
it.


>If I do as above, will it be forwards-compatible with where you want to
>take SWARM?

Yes...  although that will simply be because it's orthogonal.  I don't see
that SWARM will care about the "workflow_states" method, since being
ZPatterns-based, if you want overall state changes to be triggered by
changes to one of the propertysheets, you can do that with a trigger or
perhaps with a transition rule in the workflow plan object, depending on
how those end up shaping out.  But the convention of devoting certain
propertysheets to transition flags will make it easier to set up those
triggers or transition rules.

Just to clarify...  SWARM will assume only one true "state" per "object",
although a propertysheet might be considered an "object" with a state of
its own.  This is because a SWARM state is a path within a Plan object that
denotes a subclass ("Phase") of the object which it will behave as for the
duration of that state.  So, the only use of checklists and state flags for
SWARM's purposes would be to determine whether the conditions for an
overall state transition have been met.