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 Fri, 14 Dec 2007 06:15:30 GMT
Martin Cooper wrote:
> And I'm trying to avoid hacks like "special" values (or "special" anythings)
> that only lead to trouble. People will end up (re)using the same names, not
> realising that they're already "taken" for something they may not even care
> about, the end result being debugging hell.

And I agree with that... that's why the last iteration of what I 
suggested to Paul in this thread does away with these "special" values, 
at least partly for the reason you state.

>> Second, that doesn't sound terribly efficient to me.  Having to
>> essentially invoke a whole new request cycle, servlet invocation, all
>> the overhead that involves, sounds like a bad idea to me in terms of
>> performance and scalability.
> Huh? You're kidding, right? This is *exactly* the same, in terms of
> efficiency, as forwarding to a JSP or another Struts action. That's the
> point - it's *exactly* the same mechanism that every Struts developer has
> been using for years. If that's an unacceptable performance impact, we must
> have been screwed all along. ;-)

Ok, yeah, you got me on that one, I didn't think that through properly.

However, I believe my statement is still valid, just not for the reasons 
I was originally thinking... certainly you would agree that executing a 
class that is essentially part of the Struts RP chain is more efficient 
(assuming it's not doing something inefficient!) than forwarding to 
*any* resource, be it a servlet, JSP or what have you, wouldn't you?  I 
don't see how you could say otherwise.  Now, I'd agree that depending on 
what work is actually being done that the different may not be too 
great, but I've gotta believe there'd be a difference regardless.

>> What's the point of using a framework like Struts in the first place if
>> it can't provide something (relatively) simple like this?  That would be
>> my answer.  I don't view returning a special forward, or better still, a
>> new subclass as I suggested to Paul, as more complicated, just the
>> opposite: I see it as clearly less so.
> You mean "can't provide something [...] like this" automagically, right?
> I've suggested a way that Struts can provide this very simply, and in a way
> that will not introduce *any* new concepts to the Struts developer. It's not
> automagical, but sheesh, S1 has never been automagical. I am not in favour
> of hacking around with it now just to make it so for some relatively minor
> enhancement.

If you view this as a minor enhancement, then that's the disconnect 
here.  If it is was *just* about JSON or XML, then yeah, that'd be 
pretty minor and you might convince me.  Again I go back to the last 
iteration of what I'm suggesting, because frankly it's evolved as this 
discussion has progressed.  It opens up the door to much more than just 
JSON, XML and relatively simple things like that.  Think DataVision, 
JReports, etc.

And yeah, I'm trying to make things automagical, you're right.  Since 
when is that not desirable?  Isn't the whole point of a framework to 
remove some work for the developer?

To put it another way: why WOULDN'T we want to make things like this 
automagical if we can?  Why WOULDN'T we want to add capabilities to 
Struts that a developer gets for as close to free as possible?

>> Besides, I think the more the answer to things like this is "add this
>> piece that's not a part of Struts", the less point there is to Struts.
> At what point did I suggest adding something that wasn't part of Struts?

You suggested a servlet to render the JSON.  That's not part of the 
framework.  And I bet you're going to point out that JSPs then would be 
the same thing because after all, they're servlets in the end.  The 
point I'm making though is that what you're suggesting is something 
additional the developer has to remember to configure, some other 
component they have to bring into their project (because I presume you 
wouldn't want such renderer servlets included in the Struts JAR, correct?)

And I'm asking, what's the deciding factor as to whether something 
belongs in the framework or not?  Many other frameworks provide this 
type of thing, S2 as one big example, so why should the answer be 
different for S1?  You're not suggesting results in S2 should be 
replaced with servlets that are forwarded to, are you?

> Martin Cooper


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