You might be totally right. Thanks for helping my brain along. In fact, the new execute method should probably be for classes which do not extend Action. Because everything is stuck in TLS, it's always accessible. For regular POJO, use the new way.
Paul On Dec 13, 2007 4:59 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > 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] > >
