On Dec 13, 2007 10:59 AM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> 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 :) Given the following paragraphs, I think we might be on different planets. ;-) 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. Why do we need anything more complicated than that? -- Martin Cooper > > 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] > >
