struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <>
Subject Re: Result types for S1
Date Thu, 13 Dec 2007 22:59:01 GMT
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 W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
AIM/Yahoo: fzammetti
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 -
  Supplying the wheel, so you don't have to reinvent it!

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message