cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: Experience with workflow at Hippo Webworks
Date Sun, 07 Mar 2004 14:15:41 GMT
Guido Casper wrote:

>> Interesting. would you like to share that with us? I think it would be 
>> avery good exercise to see the two approaches one beside the other.
> I don't have interest in generating my complete workflow logic out of a 
> UML diagramm or a XML file. I remember there have been thoughts about 
> generating flowscript out of a XML file describing my page flow logic, 
> but I doubt that will ever happen. I can't grasp what that would give me 
> (now that I have flowscript available :-).

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.

> <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.

> 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;}
> I have the gut felling that this may be solved  with some piece of AOP 
> but I don't know enough about AOP and I currently don't care enough as 
> this already satifisfies my needs.
> Of course any State object allowing transitioning to NewState has to be 
> updated with the corresponding conditional logic (overriding 
> allowEnterNewState). Each state has to know about other states it allows 
> transitioning to and the conditional logic (if any) to do so.

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. But in any case, I think that states shouldn't give a damn about 
other states: transactions might need that.


Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance -
     (Blogging at:

View raw message