[Zope-CMF] DCWorkFlow Guard Expressions?
Paul Winkler
pw_lists@slinkp.com
Fri, 25 Oct 2002 10:18:12 -0700
On Fri, Oct 25, 2002 at 10:53:14AM +0000, Florent Guillaume wrote:
> An automatic transition is a transition that is automatically followed
> after another transition, if it's allowed to (by its guard).
>
(snip)
> For your problem you don't need automatic transitions, simply complex
> guard expressions (they can call python scripts).
Hmmm, I don't understand how I would do that.
Let me describe the situation, and maybe someone can
suggest if/how this could be modelled in DCWorkflow
or an alternative workflow. (I'm reading up on Openflow
at the moment, just getting started.)
I also describe below an alternative solution that's
occurred to me.
Here's what I need:
Content team works on Document foo on local server A.
When team is happy, they push foo to remote server B (using ZSyncer).
They do not otherwise have access to server B.
(that would inevitably lead to somebody editing live content, and
we don't ever want that to happen.)
This can be part of the Publish transition. No problem so far.
Retract can be made to delete the remote voo via xml-rpc.
Still no problem.
The problem is that when content team further edits foo
on local server A, the Document's state needs to
be set to "Revised" which is entered anytime foo exists
on A and B, but A is newer than B. Thus they can tell
at a glance what content is up to date on the production server
and what is not. Furthermore, if at any time foo goes away
on B (e.g. some clumsy administrator accidentally deletes it from B),
the state must be changed back to the inital state
("Private") so the content team can easily see that it's
not on B.
So it seems to me that my states depend on dynamic factors
which are not part of the workflow. They are simple
questions to ask ("does http://B/foo exist? is http://B/foo
newer than http://A/foo?") but the problem is that they
could conceivably change at any time. My states are not static. :-)
I certainly don't want to go modifying every manage_beforeDelete
etc. to make sure that it notifies the workflow, but I wonder
if I might have to.
The alternative, which is looking nice, is to leave the sync
stuff out of the workflow - just add it as another
section of actions_box, so the sync status methods are queried
at every view of the content management interface and thus are
always up to date. (of course i'll have to wrap that in try/except
in case B is unreachable).
Then I could make "Publish" a valid transition from "Published"
so you can just re-push something that's out of date or missing
from B.
--
Paul Winkler
http://www.slinkp.com
"Welcome to Muppet Labs, where the future is made - today!"