compare/contrast ajax mechanisms for integration ith spring mvc app

[ideasculptor]

I've got a web application that communicates with the server via traditional html+http and some flex/amf via spring-blazeds integration. I'm not interested in porting the core application over to ajax, as I find that back button support and other things are headaches that I don't want to deal with, and users generally prefer a page-based paradigm for online apps, anyway. However, we do have functionality we'd like to enable via ajax - things like suggestions, validation, and a couple of places where a single interaction happens via multiple forms that actually makes more sense as a single 'page unit' so I prefer to handle the transitions via ajax.

I'm looking at a couple of possible implementations, and I'm fairly agnostic about which to choose. I'm also curious as to whether there are options I should consider that I have not yet encountered.

DWR - My gripe with DWR is that it bypasses my SpringMVC layer. This isn't the end of the world, but it adds to the complexity of the app. However, given that the blazeds interaction already does the same thing, and works in an almost identical manner, it is something I can definitely live with.

JsonView via spring-json - I really like the fact that this uses the springMVC infrastructure and should be totally agnostic about how the client side is implemented. I'll admit to leaning in this direction, but I haven't done that much research yet, so I can be convinced to go another way.

XT Ajax Framework - I really don't like the look of this. It seems to be quite complex and doesn't really mesh well with the rest of my application, from what I can see (I've only read through the docs). Again, I can easily be talked into it with a good argument.


I'm curious about your experience from a performance perspective, integration with spring-security, ease of use (I'm a very fast learner, so learning curve isn't an issue so much as how much coding is necessary to support the framework once I'm up and running), client side simplicity (my front end guys are not java devs, so I'd prefer a clean separation between client and server side code), and anything else you can think of.

[sami25]

Hi,

Have a look at the following,

The Dojo support that is provided by the SpringJS, the spring JS is shipped along with webflow.

The other option is to use JQuery,

[ideasculptor]

Hi,

Have a look at the following,

The Dojo support that is provided by the SpringJS, the spring JS is shipped along with webflow.

The other option is to use JQuery,

Yeah, I'm really not as huge fan of dojo, but beyond that, I don't want to be bound to any particular js codebase on the client. Keeping the js payload that must be downloaded to the client to an absolute minimum is a fairly high priority on this project. But I'll take a look at it.

[ideasculptor]

After taking a look, spring-js is really not an option I'd consider. I hate using ajax to re-remder entire sections of a page. It can lead to all kinds of problems when those sections include javascript code, etc. As far as I am concerned, ajax should be used to pass data between client and server, but all page rendering should be handled either entirely in the client, while processing that data, or else when rendering an entire page on the server. In my experience, keeping that separation causes an app to maintain a page-centric user experience in which the browser forward and back buttons work as intended without resulting to js kludges and it allows the front end developers much more independence from the backend. Basically, spring-js feels way too much like Tapestry, to me, only without the convenience of rendering individual components unless each is rendered in a separate tile.

Whatever mechanism I choose, it will involve passing json or xml from the server to the client rather than html fragments. Perhaps I didn't read far enough into the docs, but I didn't even see json or xml mentioned in the spring-js docs, so I'm curious how one would do ajax based validation or suggestions without incorporating something like JsonView to render json back to the client outside of the spring.js framework.