Printable View
I may have a chance to work with ajax.
1 it doesn't sound like there's a need for a controller - any controller?
2 there is some need for this technology but it is deep or will it be? the client wants windows-like responsiveness on the web. i've been told that google maps was done in ajax.
I did read 4 threads about it on here and found https://dwr.dev.java.net/. I can integrate with spring.
I appreciate any thoughts you can post here.
dw
I'm currently working on some projects that could be considered 'ajax'. The main motivation for their design was that all the server-side resources can be exported as static xml files so that a snap-shot of the application can run in a pure client-side environment (for instance off a CD-ROM).
Unless you are simply loading a resource such as an xml file directly into the client and not doing anything else (see above), then you will want some form of controller, if only to do server-side validation. The main difference would be that the controller gets/sends data to javascript while the user only sees one screen/page where parts are dynamically updated without the need to submit a form or click a link.Quote:
1 it doesn't sound like there's a need for a controller - any controller?
I can't remember exactly where, but I read very detailed explaination of how google maps works (based on the author's reverse enginering). If you haven't already search http://www.oreillynet.com/ and see what you come up with.Quote:
i've been told that google maps was done in ajax.
My only other thought is that AJAX is really a fancy buzzword for something which has been evolving for a while - richer interactivity built into the client. The popularity of Firefox seems to have kicked off a round of renewed interest in the technologies from open-source and J2EE types (note that MS has supported most of the tech. for a while now). I think it is for the better, as web-applications seem to be here to stay, and the latency of most of them can be extremely annoying.
Also, I would tend to go light on the amount of custom client-side logic; I'd keep it as light as possible, mainly define a set of messages/responses w/ the main client-side code being GUI updates based on data loaded from the server. I think the server-side technologies are a lot less likely to change - and who knows, if your client decides to make the web app. available to people who are running browsers or other clients with little or no support for JavaScript, you'd be much better able to add a javascript-less mode.
Check out DWR. Works well with Spring.
http://www.getahead.ltd.uk/dwr/
hello,
do you mean that it is correct to manually write the xml response directly into the HttpResponse writer object ?Quote:
Originally Posted by rrsIPOV
It sounds so a low level approach to me..
Doing what?Quote:
I may have a chance to work with ajax.
If you're building a business app then one option might be to use something like SpringMVC as the foundation, and then sprinkle some Ajax around.
Scriptaculous also has some Ajax resources, and some cool javascript effects that are easy to apply and complement an Ajax approach.