Martin Cooper wrote:
1) We simply provide servlets / other entry points that can accomplish the
rendering to JSON / XML / whatever. The developer can then configure those
as global forwards and use them as any other forward. This makes the process
identical to what developers do now, but gives them the additional rendering
capabilities.
This was interestingly exactly what I was thinking originally :)
I was thinking about introducing Freemarker into the mix... then, when
Struts started up, it would insert some "automatic" global forwards,
"json", "xml" for example. Then a Freemarker template is used to render
the output. But, I'm not sure how well Freemarker will truly do JSON or
XML in a generic way, whereas the json-lib I've been using so far is
very simple (I believe it can do XML from JSON too, so we can get XML
from it as well, although maybe not as efficiently as possible).
But, that means we'd still essentially have "special" values though
because somewhere in the processing chain it would have to recognize
that the forward name specified maps to a Freemarker template. But,
it's a special value within the same overall architecture, so I think it
would be OK.
I'm also not sure what the most elegant way to detect a Freemarker-based
forward would be... maybe it's simply if the path doesn't begin with /
then we assume it's a classpath specification, i.e, something like
"org.apache.struts.results.JSONResult.ftl".
I think doing it this way would also mean that a developer could add a
new result type easily because it's just a new global forward entry,
with a path pointing to the Freemarker template, and so long as its in
the classpath we're good to go.
2) We not limit this to rendering the action form. Rendering the form might
be desirable in some situations, but in many others, it would be some other
bean that should be rendered, not the form bean. We could define an
attribute under which the bean is stored, and the renderers could look for
that and perhaps fall back to the form bean if it isn't there.
Yeah, that's a good point... maybe the best way to do that is with some
<set-property> elements defined at the action level... that would also
address Laurie's point about parameterization. Shouldn't be a big deal
to make the ActionContext available to the Freemarker template, so it
then has access to the Action, ActionForm, whatever else, and we could
look for setting on the action (I think that's the right place).
It's a different approach than what I've been discussing so far in some
important ways though, so what does everyone think of it? I can
probably get it at least working by late tonight and can throw it up
somewhere for everyone to look at, I don't think it's much of a leap
really effort-wise.
--
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]
