tags:

views:

199

answers:

6

Our team is experienced in web development (tomcat/Oracle) but not with AJAX on our existing projects. This is new technology for us, so I want to introduce this carefully and correctly.

What should I look at in terms of frameworks or best practice or common pitfalls?

+4  A: 

read this:

and use a library such as jQuery, mootools, or YUI it'll save you many headaches with cross-browser implementation. this will show you why you want to use a library.

Owen
+3  A: 

My first recommendation would be to explore the different frameworks available and see what your team prefers in terms of coding style. Most of the frameworks have the same basic features so a lot of it comes down to preference. I prefer jQuery, so that is my first recommendation, but I worked with YUI, MooTools, Prototype and EXT JS before making my decision.

Secondly, I would recommend working AJAX functionality as a progressive enhancement, allowing your apps to work with and without JavaScript. I find that this approach also ensures a solid, working application before worrying about adding the bells and whistles.

Head First Ajax is a good book IMO for getting started with the basic concepts behind working with Ajax. It would probably be a good place to start for your team to gain some knowledge of what is happening behind the scenes in whatever framework you choose.

Andrew Van Slaars
A: 

first, look at the user interface you already have, and consider where it might make sense for its elements to be able to change/react independently. This is where your ajax enhancements might make sense

second, look at libraries as noted in the other answers (I like AJAXPRO for its simplicity, but it has been discontinued)

if you find that all of your page elements tie together and cannot change independently, then there is really no need for ajax

otherwise, consider how you will access the page state from your ajax enhancement points - depending on which ajax framework you use, you may or may not have access to the entire page object, session state, original request parms, etc. Consider these issues up front to avoid coding yourself into a hole and/or having to make messy workarounds.

Steven A. Lowe
+1  A: 

One thing we struggled with when starting to use ajax was how often to use it.

We had no exact requirement as to where we were supposed to use ajax and not, and initially we erred to the side of using it too much. This affected application complexity quite a lot.

If you think of your inter-page-structure as a state-machine, ajax introduces nested state-machines within each page-state. The moment your sub-state machine ends up with a number of distinct states (I'd say anything over 2), you should think really hard about using a traditional approach.

The best starting point is to try to get a mix og full page reloads and ajax, and be conservative until you're sure you're getting really good at it.

krosenvold
+1  A: 

Don't use it where you don't need it.

Long running operations that need to send the client some status updates? Use AJAX.

Markup for major UI elements (menus, ect)? Use plain old HTML.

Basically, use AJAX for transmitting data only. If you try do fancy things like dynamically pulling in UI elements on the client side with AJAX, you are in for a world of hurt when you get a client who wants to use ie5 (they exist), or a non-pc based browser.

Jamie Penney
A: 

If you were on .Net or Mono I would encourage you to use Ra-Ajax which abstracts away JavaScript completely. Though I work for Ra-Ajax (inventor) so I am biased...

Thomas Hansen