On Dec 12, 2007 10:12 PM, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> So, now that I've gotten my build problems sorted out, I was able to
> make some quick progress on what I wanted to work on, enough that I want
> to run this by everyone before I spit, polish and submit patches.
>
> Ted and I were discussing some ideas at The Ajax Experience back in
> October, specifically on how we could make S1 a little more
> AJAX-friendly and useful to developers doing RIA development. One of
> the ideas I had was the ability to have, essentially, "result types" in
> S1, ala S2.
>
> As a concrete example, say I have an Action that does this at the end:
>
> return mapping.findForward("JSONResultType");
>
> That mapping name would be a value specially recognized by Struts. The
> result of doing that would be that the response is a JSON representation
> of the appropriate ActionForm. One can easily imagine an XMLResultType,
> a FreemarkerResultType, a DataVisionResultType, and so on.
I like the idea, but not this particular approach. I especially don't like
the "special values" aspect to it. I'd prefer something like:
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.
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.
--
Martin Cooper
>
> Note that the developer *does not* need to add any configuration to
> struts-config, they have only to specify that forward name, and the
> ActionForm to JSON conversion is automatic.
>
> I have this JSONResultType working right now, and it turns out it's a
> minimally intrusive change to the S1 code base overall, consisting of:
>
> * Some frankly minor changes to two Chain Commands
>
> * The addition of a new package containing one new class (the class that
> actually generates the result output, more to follow as new result types
> are implemented)
>
> * Some new dependencies: one during build (json-lib), and four at
> runtime (if using that result type): Commons Collections, Commons Lang,
> JSON-Lib and EZMorph).
>
> To be clear, this code isn't complete and ready immediately, it's POC
> grade right now, but it's not too far off either, maybe an hour or two
> worth of polishing.
>
> So, does anyone else think this is a worthwhile exercise? I certainly
> think it is: the ability to have automatic conversion of an ActionForm
> to JSON, XML, or whatever else, means S1 can become a true service
> provider for AJAX-based clients with no real effort on the developers'
> parts. It's not a huge change to the Struts code base, doesn't break
> compatibility in any way (I suppose unless someone happens to have the
> exact forward names I'm proposing here in their app already), and aside
> from the added dependencies, I don't see a down-side.
>
> Thoughts?
>
> 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]
>
>
