struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frank W. Zammetti" <fzli...@omnytex.com>
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

--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: fzammetti@hotmail.com
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message