Paul Benedict wrote:
I am all for it. I was thinking the framework needs these additional
enhancements to support it though:
* A new Command to expose the ActionContext as a ThreadLocal variable
* New execute() method could then contain no parameters
* Allow returning void (equal to null), String (result/forward name), or
ActionForward
How do you then propose to keep backwards-compatibility? How would
existing Actions continue to work without change?
Another way to do it might be to subclass ActionForward, calling it
Result. Then, after the Action executes, we try to cast the result to
Result, and if we catch a ClassCastException, then we have a plain old
ActionForward and we process it same as always, but if the exception
didn't occur then we have a Result and we can go off and do "result
things(tm)".
This has the benefit of zero impact on existing application code, and
isn't in any way a big change. You might argue it's a little ugly
internally, and I'd agree to some extent!, but I don't see it as being
too bad. I like the lesser degree of change myself.
Paul
Frank
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
and "JavaScript, DOM Scripting and Ajax Projects"
(2007, Apress, ISBN 1-59059-816-4)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
