How do we bake Ajax into Struts and Spring MVC?
I see a trend happening here. The next version of WebWork, as well as Tapestry and JSF are all embracing Ajax technologies. By "embracing", I mean they're not only using them, but they're making it easier for us to use them.
After using XmlHttpRequest in my last two projects, I think this is a must for Struts and Spring MVC as well. The technology is very cool and customers absolutely love it.
The question is how do we bake it in? WebWork makes it easy because its tag libraries are backed by customizable Velocity templates. With Struts and Spring MVC, it seems the best way would be to use tag libraries, but maybe there's better alternatives. Do they each need an AjaxAction/AjaxController or something that allows DWR-type stuff?
What are your thoughts? You might argue that using DWR should suffice, but w/ everyone else (even Rails) baking it into the framework - I see no reason why Spring MVC and Struts shouldn't do the same. You are using these frameworks to develop kick-ass UIs aren't you?
Posted by Don Brown on April 15, 2005 at 03:32 PM MDT #
Posted by Ahmed Mohombe on April 15, 2005 at 03:34 PM MDT #
At my company, we just finished up a project using invisible iframes to do a similar technique (we used the invisible iframes because we need to work on browsers that don't support XmlHttpRequest _sigh_). We did alot of work to make it so that the user can move between various modes in our control and everything works great.
Until we did a focus group study and users started to hit the back button. And when they didn't go back to the previous mode (instead it went back to the previous page), they pretty much freaked out. We have some thoughts on how to fix this but it turns out to be a rearchitecture of our framework for doing AJAX style interaction.
Has anyone else run into this? I am not sure sure how to reconcile the demands of users who don't want page refreshes but want to keep the functionality of the back button.
Maybe some of these AJAX implementations for the various web frameworks could take this into consideration. Any thoughts?
--> John
Posted by John Townsend on April 16, 2005 at 03:00 PM MDT #
Posted by PJ Hyett on April 16, 2005 at 09:42 PM MDT #
For the back button problem, one partial solution is to open the webapplication in a window without a button bar. This way the user knows that he is in a "webapplication" and not a normal web page(this is something that every user can learn). The most of the users use the "back" button, and not the shorcut key, so it will prevent such problems if the button bar is not shown. This is used by a lot of online banking of online trading applications. The only problem is not to forget to offer a clear an precise navigation (navigation bar and menus), cause the user can't use the back button anymore.
In other applications a "fake button bar" is a good solution too. The users gets after login a window without a button bar, but instead, a customized simulation of a button bar, even with application specific actions, and of course with back and forward buttons, but with server side implementation, so that back and forward make sense from a server point of view. It takes a little to implement such a thing, but it's a very good solution and reusable in may projects. Unfortunately I found no open source project that does this, only "in house" commercial solutions.
Ahmed.
Posted by Ahmed Mohombe on April 16, 2005 at 10:19 PM MDT #
Did we all forget why frames suck?
just my .02
Posted by Alonso on April 17, 2005 at 03:11 AM MDT #
Posted by Stefan Kleineikenscheidt on April 17, 2005 at 11:02 AM MDT #
Posted by John Townsend on April 17, 2005 at 02:58 PM MDT #
Posted by Nick Lothian on April 17, 2005 at 11:27 PM MDT #
Posted by Greg Ludington on April 18, 2005 at 05:17 PM MDT #
Posted by Guide Through the Dark on April 19, 2005 at 08:33 AM MDT #
Posted by Mark Womack on April 26, 2005 at 09:41 PM MDT #
Posted by amalraj on December 02, 2005 at 02:02 PM MST #