This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
Hopefully directed at the author, but anyone else who has dabbled in Ajax.
I've been having a go at my own Ajax application and paying close attention to the design process at the same time.
In the experience of others, are there best practices in terms of how to define how to delegate application knowledge (eg what does the client 'know', what does the server 'know'), how to define communication, how to prevent the layers blurring into each other?
To extend the question, is there a particular direction you started from and work towards the other side? For example, I mocked a simple client (little or no JS, no server interaction) then I wrote the server. I defined the server interactions in a couple of simple servlets then moved to integrating into the client, but I've been doing the the thin-client thing for too long and I keep making decisions based on that knowledge. My app currently reloads and caches images in JS, I still haven't gotten to the 'Ajax' bit
I just started working with Ajax, so here are my few cents.
-I start by building a JS shell that has all the inner workings set. -Once that works I build the AJAX to get the info to and from the server -I use DWR for quick setup. So basically JS just calls methods which are mapped to a server's class which returns the data in some structure and changes the state of the page (JS which has already been debugged)
If you are thinking about writing an Ajax application with some server side part then you should be thinking in SOA terms. Think of your server in terms of exposing services.
Pragmatically I would do the following:
Christian Author: Ajax Patterns and Best Practices