Me parece que mucho material sobre AJAX un tanto alarmista…. no sé… lo complican demasiado, al menos a mi parecer. Muchas personas han estado utilizando métodos similares mucho antes de que a alguien se le ocurriera llamarlo AJAX. Y realmente no es tan complejo como muchos lo hacen ver.

Así que para muestra un boton:

function createRequestObject()
{
  var ro;
  var browser = navigator.appName;
  if(browser == "Microsoft Internet Explorer")
  {
    ro = new ActiveXObject("Microsoft.XMLHTTP");
  }
  else
  {
    ro = new XMLHttpRequest();
  }
  return ro;
}
var http = createRequestObject();
function sndReq(action)
{
  http.open('get', 'rpc.php?action='+action);
  http.onreadystatechange = handleResponse;
  http.send(null);
}
function handleResponse()
{
  if(http.readyState == 4)
  {
    var response = http.responseText;
    var update = new Array();
    if(response.indexOf('|') != -1)
    {
      update = response.split('|');
      document.getElementById(update[0]).innerHTML = update[1];
    }
  }
}

Esto crea varios objetos para recibir y enviar la petición así como una función para manejar la respuesta. Podés incluir este js en tu página si querés. Ahora.. para hacerlo funcionar es necesario ejecutarlo con un evento onClick o a un href común como este:

<a href="javascript:sndReq('foo')" xhref="javascript:sndReq('foo')">[foo]</a>

Esto significa que cuando alguien haga clic en esta liga lo que sucederá será es que se envie una solicitud a rpc.php?action=foo.

Y en rpc.php deberías tener algo como esto:

switch($_REQUEST['action']) {
case 'foo':
/* HACER ALGO! */
echo "foo|foo done";
break;

}

Ahora… analicemos un segundo el handleResponse. Lo que hace es que parsea el string “foo | foo done” y lo corta en el “|” y usa lo que sea que esté antes del “|” como el ID del elemento DOM en la página y lo que esté despues como el nuevo innerHTML de ese elemento.

Esto significa que si tenés un div como este en la página:

<p id="foo">&nbsp;</p>

Cuando des clic en el link, dinámicamente va a cambiar a:

<p id="foo">foo done</p>

Y eso es todo. Lo que sigue es solo agregar y construir sobre esto. Reemplazando la simple respuesta “id | contenido ” con una sintaxis XML más rica y/o hacer la petición más compleja tambien. Antes de instalar a ciegas una librería AJAX, dale un vistazo para ver si hace lo que necesitas, que muchas veces son más de lo que se requiere y el usuario termina descargandolas gratuitamente.

Vía Ajaxian me entero de dos tutoriales/manuales de que es correcto y que no es correcto en prototype, o sea, aprender a ocupar prototype y sacar el máximo del provecho.

En ambos se muestran ejemplos de que haría uno, y como se podría mejorar, por ejemplo:

Forma Antigua
Event.observe(’myContainer’, ‘click’, doSomeMagic);

Forma mejorada
$(’myContainer’).observe(’click’, doSomeMagic);

Además de otros tips de como optimizar mas nuestros scripts y que sean mas eficientes.

Enlaces:
How well do you know prototype
How well do you know prototype II

Dato: También tienen la API para ver en mas detalle y con ejemplos de uso.

Bret Victor de WorryDream publicó recientemente un documento llamado Magic Ink: Information Software and the Graphical Interface en el que muestra de un modo bastante claro y con ejemplos una perspectiva diferente del diseño de interfaces y su aplicación a productos de información.

Muy bueno

Es muy común escuchar gente argumentando sobre si crear sitios RIAs sobre Flash o un RIAs´s sobre AJAX sin percatarse de que este es un modo erróneo de iniciar un proyecto. ¿Podrías discutir con un arquitecto sobre construir una casa totalmente en concreto o en madera? no verdad?, se construye cada parte con el material más adecuado. Aveces construís una bodega toda de madera o una casa en ladrillo, pero muchas veces vas a querer usar el mejor material para cada sección de la casa. Construir la base en concreto, las paredes y el cielo raso en madera si es el caso.

Los sitios y las aplicaciones web tiene que ser tratados del mismo modo. Dividirlo en componentes y crear a partir de eso. Usar la herramienta correcta para cada componente. Si te funciona mejor en HTML/Javascript, adelante. Si lo lógico es usar Flash para qué carajos perder el tiempo tratando de hacerlo en java si te va tardar 3 veces más?. Por suerte tenemos una buena variedad de ejemplos en internet:

Uno de mis favoritos es Google Finance. Ellos sabiamente utilizan HTML y Javascript para las cosas en las que se pueden aplicar y cuando necesitan mostrar un gráfico atractivo utilizan una gran aplicación creada en Flash a la que le comunican los datos usando javascript. Así el flash controla el javascript y viceversa según lo necesiten.

Otro ejemplo digno de ver es el bastante conocido Flickr. Ellos iniciaron usando Flash para mostrar todas las imágenes, los comentarios y una barra lateral junto a cada foto. Bien para comenzar, pero pronto lo reemplazaron por una versión mucho más eficiente de las notas y la barra lateral en HTML que funcionan tan bien como la versión anterior. Solo conservaron una pequeña parte en flash que permite rotar y previsualizar las imágenes antes de guardarlas. Bonito no?

Así que la próxima vez que inicies un proyecto web, en lugar de pensar “mmm, Flash o AJAX??” piensa el sitio desde una perspectiva más amplia, intenta estructurarlo en pequeños componentes, y escoge el lenguaje o soporte adecuado para cada uno.