struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <>
Subject Re: Result types for S1
Date Fri, 14 Dec 2007 05:51:45 GMT
On Dec 13, 2007 9:14 PM, Frank W. Zammetti <> wrote:

> Martin Cooper wrote:
> > Given the following paragraphs, I think we might be on different
> planets.
> > ;-)
> Could be... some would say I rent a summer home on some distant world :)
> > I don't see that you need Freemarker or anything like it, nor do I see
> any
> > reason you couldn't continue to use the json-lib package you're already
> > using. Why not simply add a rendering servlet that does the work of
> picking
> > up the appropriate bean and rendering it by calling into the library,
> > sending the output to the servlet output stream? If you do that, you
> need
> > *no* other changes to Struts. Anyone who wants to use it simply adds the
> > rendering servlet to their web.xml, adds a global forward (or more than
> one,
> > if we want to parameterise things) that forwards to the servlet, and
> then
> > uses that as the target of their actions. Done.
> I wouldn't like this for two reasons... first, it's something additional
> the developer has to do on top of Struts.  I'm trying to avoid that.

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.

> 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. ;-)

(Although, I think you're right WRT Freemarker... as the idea has
> evolved from discussion with Paul here, I tend to agree with you on that
> at this point.  Freemarker could well be another result type, just like
> in S2, but it shouldn't be necessary for the JSON or XML result)
> > Why do we need anything more complicated than that?
> 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

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

Martin Cooper

I mean, after all, shouldn't we then have told Musachy that the JSON
> plugin should be a filter, servlet, or something like that?  I haven't
> seen a single person say that, and rightly so.  I don't see it being any
> different, except that S2 has a plug-in mechanism for things like
> that... but at the end of the day it's still a part of the framework, if
> only a loosely-coupled one, not an external piece that I as an
> application developer then have to manage.
> > Martin Cooper
> Frank
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> AIM/Yahoo: fzammetti
> MSN:
> 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:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message