Laurie Harper wrote:
Or stick with mapping.findForward(something) but provide a mechanism for mapping that result type to the appropriate (JSON/XML/etc) rederer in struts-config.xml. That would eliminate any concern over clashes with existing action return strings (small though the risk is), and would be consistent with existing declarative semantics.

With that, it could be easy to make the 'result providers' such as JSON serialization, XML serialization and so forth plugable/configurable and/or parameterizable.

For example:

  <action name="/orders" ...>
    <forward type="json" name="json-brief"/>
    <forward type="json" name="json-brief">
      <!-- JSON serializer parameters go here -->
    </forward>
    ...

I was thinking along those lines too, especially in terms of parameterization... but, I think Antonio still has a valid point in terms of findForward() meaning one thing, and doing it this way in a sense "overloads" that meaning, which arguably isn't as nice.

I re-implemented it now by adding a renderResult() method to ActionForward, and that works nicely. That code I think is fairly good now, could create a patch for it. But...

There's two concerns left... one is parameterization. First, let me show you where I am right now:

return mapping.renderResult("json", response, inForm);

I think that addresses Antonio's concern. Now, for paramerization, I'm thinking simply using the <set-property> on the Action might be fine... then, this call would become:

return mapping.renderResult("json", response, inForm, this);

Each renderer could look for specific attribute of the Action to configure it.

Also, I just saw Martin's note, and the point about not always using the ActionForm is a good one, so one of the things the renderers could look for is an attribute, maybe call it simply "beanToRender". That way, if the Action wants to return another object as JSON, they just point that attribute at the object and it's good to go. If that attribute is null, or not present, the ActionForm is used.

The second concern... well, the second concern I'll skip for now because I want to go reply to Martin's reply specifically because it might change all this anyway :)

L.

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]

Reply via email to