I guess first off, try using Maven to build OSWorkflow. Then through using Maven you kinda pick up bits of Jelly through osmosis :-).
I hear good things about Maven, unfortunately I'm totally strapped for time right now, so I think I'll have to skip this until someone else in "OpenSymphony" can maven-ify their project first so that I can spring board off of that.
[snip]
This kinda mirrors what a workflow engine does. It has a core model (Process, Step, Action or whatnot) typically implemented via beans (like the Swing widgets) and have their own protocol for connecting themselves together, adding steps to a process etc. Then you want to assign arbitrary actions/scripts to points in the bean graph.
[snip]
In terms of implementation, JellySwing uses a single ComponentTag class to implement all the Swing widgets and a single ActionTag to bind actions to components. Maybe a similar approach could work for OSWorkflow.
[James Strachan's Radio Weblog]
In OSWorflow there are currently several support ways for an arbitrary code to be executed before or after a workflow transition: class (via Classloader, JNDI, EJB, or local EJB) that implements FunctionProvider. Alternatively, you can provide beanshell code and the variables inputs, args, and vairables are auto-defined to be in scope and have the same meaning that they do in FunctionProvider. Lastly, you can write a BSF script which works just like beanshell.
Now it would seem to make sense for me to just add a new type: jelly, like so:
<function type="jelly">
<arg name="jellyscript">
... magic here ...
</arg>
</function>
Would that work? Maybe I need to take a closer look at the API to figure all this out. If that _would_ work and I could provide those three Maps that are in FunctionProvider, that would be very cool. Once I got functions working, I could add validators, registers, and conditions support as well.
5:45:54 PM 
|
