cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <gian...@apache.org>
Subject Re: Experience with workflow at Hippo Webworks
Date Sun, 07 Mar 2004 20:47:26 GMT
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).

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

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

-- 
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance - http://www.orixo.com
     (Blogging at: http://www.rabellino.it/blog/)

Mime
View raw message