Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4761B935.8020305@omnytex.com>
Date: Thu, 13 Dec 2007 17:59:01 -0500
From: "Frank W. Zammetti" <fzlists@omnytex.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Struts Developers List <dev@struts.apache.org>
Subject: Re: Result types for S1
References: <4760CD4A.70107@omnytex.com>
 <fjrmh5$4ni$1@ger.gmane.org>	 <47617D37.108@omnytex.com>
	 <b9e663070712131100y6549c6f5lde9a5b1526893f8b@mail.gmail.com>
	 <4761842B.5030107@omnytex.com>
	 <aae96ca0712131200l78fbd544pd35e080098a19b51@mail.gmail.com>
	 <b9e663070712131208v1728775cte8f6ac562e4bf4ea@mail.gmail.com>
	 <4761934A.6010002@omnytex.com>
	 <b9e663070712131245s119bae5fqc16850da53bee8e0@mail.gmail.com>
	 <47619DB1.4050304@omnytex.com>
 <b9e663070712131428t4069e4d2l2ba6936901ae53f7@mail.gmail.com>
In-Reply-To: <b9e663070712131428t4069e4d2l2ba6936901ae53f7@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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