Hi Craig,
> You can actually include parameters in the request URI of the forward, but
these
> wouldn't really be dynamc. On the other hand, request attributes are
still
> maintained even if you forward to a "subfunction."
I'll do that for now.
Having them in the forward was a way to hide the mechanics behind that: a
request parameter or looking and pre-instancing the callee ActionForm or
something else...
> 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'm definitely interested in that idea and I would like you to developp on
that subject after the release of version 1.0.
I can't think of a simple "script" definition with a semantic rich enough
that would lend to Action classes disappearance. Even identifying the
discrete "tasks" seams a challenge to me. It just reminds me of the today
definition of a "logon" action and the proposal of the inclusion of the
<logon> tag into the libraries...
Pierre M�tras
