Paul Benedict wrote:
I said new method, I didn't say replace the previous method :-) I wouldn't
implement anything that didn't allow current Struts actions to work. It's
all blue sky thinking so there's a lot you can help me figure out.
No, I knew you wouldn't do that... although it wasn't initially clear to
me how it would still be compatible, I had no doubt that was just my
lack of understanding and you had that answer :)
So, let me think this through out loud, make sure I'm on the same page
as you...
I'm a Struts developer, and I upgrade to 1.4 where all this stuff
presumably is. Ok, so none of my existing code breaks, good to go
there. But, I want to use this new JSON capability, and let's think
simplest case: I just want to render my ActionForm as JSON and return
it, no options to fiddle with or anything like that.
So, I need to implement this new version of execute(). Not too big a
deal. I'm OK with it so far. But what if I want to take an existing
Action and do this? Still not a big deal I think: implement the new
version of execute(), call the existing execute(), ignore the returned
ActionForward and do whatever I need to do to get the JSON output to
happen. Not a big deal.
I don't care about the ThreadLocal stuff, or the alternate execute()
version, unless I want to.
The only objection that comes to mind for me is that maybe having two
different types of execute() methods is a bit more confusing than it
needs to be. I don't think it's the kind of thing you can deprecate
over time, there's too big an installed base to do that with.
My puny brain needs simplicity :) So, I'm wondering if there's not a
simpler answer, which is my roundabout way of asking: what do you think
of my suggested approach to this? Just to recap:
>> 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)".
Because to me, while what you propose isn't exactly rocket science to
implement or make use of, I think this approach is simpler still, and
requires very minimal changes to the codebase, also something I strive
for (not just with Struts either)
...or did you have some other motivation for those changes besides this?
Did you have other plans that hinge on these changes?
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]
