cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Stuyts <>
Subject Re: Experience with workflow at Hippo Webworks
Date Mon, 08 Mar 2004 10:38:14 GMT
On Sun, 07 Mar 2004 21:47:26 +0100, Gianugo Rabellino <> 

> Guido Casper wrote:
>> Gianugo Rabellino wrote:
>>> For one, this might buy usage of some well-established worflow 
>>> description languages, such as XPDL or BPEL: this would mean, in turn, 
>>> being able to use existing tools to manage the workflow configuration.
>>> This is a very important point IMO: workflow configuration shouldn't 
>>> belong to programmers: it's a job for business people who shouldn't 
>>> give a damn about Java/Javascript/XML, then need drawing tools.
>> That's perfectly fine. It just doesn't reflect my current use case :-) 
>> I can imagine something like that for workflow logic just not for page 
>> flow logic.
> What is the difference among the two? "Page flow logic" means navigation 
> to me, while workflow (in CMS) is a way to describe formally a process 
> of any kind that affects the lifecycle of a resource. Now, this actually 
> means "how a resource gets published" in its most simple incarnation 
> (and granted I've seen so many overcomplex workflow in planning stage 
> become a "publish" button in production), but ir could be more complex 
> than that.
>>>> <workflow-manager>
>>>>   <state name="tobeprocessed" class="TobeprocessedState">
>>>>     <entering-action class="TobeprocessedAction"/>
>>>>   </state>
>>>>   <state name="beingprocessed" class="BeingprocessedState">
>>>>     <entering-action class="BeingprocessedAction"/>
>>>>     <leaving-action class="LeaveBeingprocessedAction"/>
>>>>   </state>
>>>>   <state name="tobereviewed" class="ToreviewedState">
>>>>     <entering-action class="TobecheckedAction"/>
>>>>   </state>
>>>>   ...
>>>> </workflow-manager>
>>> I'm afraid it's not that simple. Your workflow allows only for a 
>>> linear flow, where you have only one way to go in the opposite 
>>> directions (back and forth). But quite often you need to be able to 
>>> model n ways in or out, you might need conditionals, you might need 
>>> vetoes, and so on and on: workflow is a messy beast to handle.
>> Gianugo, this configuration is not meant to be a description of my 
>> workflow.
>> It's a definition of what state objects are available.
> Doesn't quite looke like that: you seem to be mixing states and 
> transitions, by explicitely telling States which are the back and forth 
> states (here transitions are opaque). IMO you should have lists of 
> states, list of transitions and then something to glue them together 
> (much like woody^H^H^H^H^Hcforms does for definition and template).

I do not agree with you here. A state machine is a single concern for me. 
Separating a state machine into states and transitions which are defined 
at different locations makes everything more difficult to understand.

The Lenya workflow definition XML places the transitions below the states 
and I find this very inconvenient. A transition is bound to the source 
state. When I am in a particular state I want to know where I can go next. 
I have never needed to know where I came from. If you care about this, 
then you don't have a state machine (maybe you should split states). The 
current state should provide enough context for handling the next action 
that gets invoked.

The only reuse I see are the functions that get called for evaluating 
conditions, when entering a state and when leaving a state.

>> The actual workflow is made up of the State objects themselves (as I 
>> said, the workflow is coded in Java, not in XML). Actually "State 
>> object" might be misnamed (I just took it from the state pattern) as 
>> they don't hold any state (or other data) but get instantiated by the 
>> workflow engine when reading the current state of an object. They just 
>> hold the conditional logic. This means, looking at the state objects 
>> you don't see the overall workflow. But that's the whole idea. You just 
>> code isolated steps and decisions of workflow since every workflow may 
>> be broken down into isolated steps.
>> The alternative would be to have a giant nested case statement.
> Well, isn't it what the actual workflow is? What you do in the typical 
> scenario is:
> a) define states;
> b) define transitions;
> c) persist the state as an object attribute;
> d) get the state attribute and run a gian nested case statement.
> The State pattern embellishes all this mess, but it's still there 
> nevertheless: somewhere you have to put the switchboard anyway.
>>>> The major drawback currently is that my AbstractState has to know 
>>>> about all the other states (to prevent each State class having to 
>>>> know about all the other states) and (when adding NewState) has to be 
>>>> updated with: allowEnterNewState(doc, user) {return false;}
> Hmmm... I see that all your samples refer to user objects flying around: 
> aren't you mixing concerns here? User verification belongs to the 
> authorization level...

The authorization has to be performed on individual actions and not on the 
whole object. Also the roles of a person are not global, but document 
specific. If you have a big site it is possible you have an editor for 
each section of the site. If the authorization level is capable of 
performing this kind of authorization, the authorization should be moved 
here ofcourse.

>>> This sounds a bit overwhelming, there are too many dependencies to 
>>> account for and you end up with a very proprietary and not reusable 
>>> code.
>> What depencies do you mean? Actually I found changing workflow very 
>> easy and flexible as long as you don't come up with new states.
> ... which is exactly the point of user-defined workflows.
>> It is true that the state objects themselves are not reusable (and are 
>> not meant to be) but so would be any construct describing the actual 
>> workflow (which is the only thing the state objects actually do).
> I can live with actual workflow not be reusable, but there must be a way 
> to reuse state objects...
>>> But in any case, I think that states shouldn't give a damn about other 
>>> states: transactions might need that.
>> Yes, maybe they are misnamed. Just replace "states" with "transaction" 
>> (or even better "transitions").
> Yepp, transitions of course, sorry for the misnaming. :-)
> Ciao,

Johan Stuyts

View raw message