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
--
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]
