> One of the ideas I've been thinking about (for a Struts 1.1
timeframe) is to
> support a more "workflow" oriented mechanism for defining actions.
The thought
> would be that an application developer would decompose the business
functions of
> the application into discrete "tasks", and then glue them together with
> "scripts" defined in the struts config file. Struts could then include a
> standard Action that executes the script -- the net effect would be
to reduce
> (or possibly eliminate) the need to write Action classes yourself.
In such an
> environment, chaining functions together would become as simple as
writing the
> appropriate tasks into a config file.
>
> Does this sound like an interesting direction to pursue?
I'd actually -1 on that. although I don't know how loud my voice
would be.
The reasons would be that it'd create another layer, a scripting
language that we'd define. It'd make it harder for new people to
learn and cause bloat in the framework. At the moment, it's
a lightweight yet still extendible framework that allows
for the customisation we might need. We'd then need to work
to make it a fully featured XML/etc based language, that
yes would be useful, but I don't think should be done.
Instead, we could create the tasks, but still allow the Action
class to define which class is called and how, with our defined
arguments. But wouldn't this clash with business oriented session
EJBs, which should supply this function?
