[Zope-PTK] content states
Mon, 17 Jul 2000 16:44:34 +0100
Shane Hathaway wrote:
> Steve Alexander wrote:
> > Portal Content with Multiple States at once
> > -------------------------------------------
> > At present, content in the PTK stores its review_state as a single
> > string, accessible as the attribute review_state.
> > The attribute review_state is indexed in a portal's SiteIndex as a
> > FieldIndex.
> > I propose that the PTK's state handling be generalised so as to be able
> > to hold many different kinds of state concurrently, and retain the
> > current functionality of being able to search on content's state,
> > without an explosion in the number of fields indexed in the SiteIndex
> > catalog.
> AHA! I think you have just identified the bulk of what has been called
> "pluggable workflow". In a workflow, a document can pass through
> different hands, each user performing such tasks as:
(altered the order of your scenarios)
> - Review before public posting
> - Review before front-page posting
> - Spelling check
> - Make read-only (the user is no longer allowed to modify the doc;
> perhaps this should mean moving it to a different place)
> - Grading by an instructor
Yes. Need something richer than what is there to keep an audit trail,
though. Perhaps this can be delegated to the Portal... or some other
specialist (small "s").
> - Conversion to different formats (such as MSWord->HTML)
> - Translation to other languages
Not sure how this fits in... you seem to be implying keeping track of
multiple versions of content.
> Do you think content_state as a PersistentMapping would be rich enough
> to handle all of these possibilities?
I've just started implementing this for my project. (My current itch...)
It gets a bit neater if I have a ContentState or MultiState class of
objects, but I'm not doing that on the first iteration.
The audit trail bit is where ZPatterns could really help. The
AuditTrails specialist provides an AuditTrail propertysheet to Parties
that said specialist has been told had a state-change event.
For now, I don't need an audit trail, so I'll stick with the simple
implementation to check it works in terms of not breaking PTK :-)