Continuamos con la traducción de la segunda parte del artículo escrito por Cameron Adams: Ajax: Usable Interactivity with Remote Scripting. En el que vemos como implementar paso a paso, mediante la creación de un formulario para el envío de e-cards, el objeto XMLHttpRequest.
Para entender a cabalidad este artículo, debes leer su primera parte: AJAX: Usabilidad Interactiva con Código Remoto.
Ejemplo 1: Implementando XMLHttpRequest
En una aplicación tradicional servidor/cliente, el formulario ecard completo tendría que ser enviado al servidor, comprobado, y devuelto al navegador antes de que el cliente tome conciencia de si su número de recibo era válido o no. Con el modelo de scripting remoto, somos capaces de comprobar el número de recibo, en cuanto el usuario ha terminado de llenar aquel campo. De esta manera, cuando un usuario envía el formulario, el navegador ya habrá identificado si los datos son realmente válidos.
El primer paso, la comprobación de los datos remotamente, es conocer cuando el usuario ha ingresado un valor en el campo de número del recibo. Esto puede ser detectado usando un evento onchange para el campo. Un "cambio" sobre un campo de texto es registrado siempre que el usuario modifique el valor del campo de texto y luego cambie de campo (por ejemplo: Hacer clic en otro campo ó presionar Tab). Esto es normalmente una buena indicación de que el usuario ha terminado de llenar el campo, y que los datos que este contiene pueden ser procesados. Pero capturando este evento onchange, podemos decir a nuestro script que empiece a validar el contenido del campo:
receipt.onchange = onchangeReceipt;
onchangeReceipt es una función que se ejecuta cuando el evento onchange es llamado. Es dentro de esta función que inicializamos nuestro objeto XMLHttpRequest y enviamos los datos relevantes para ser comprobados:
var requester = null;
function onchangeReceipt()
{
/* Check for running connections */
if (requester != null && requester.readyState != 0 && requester.readyState != 4)
{
requester.abort();
}
try
{
requester = new XMLHttpRequest();
}
catch (error)
{
try
{
requester = new ActiveXObject("Microsoft.XMLHTTP");
}
catch (error)
{
requester = null;
return false;
}
}
requester.onreadystatechange = requesterExecuteAction;
requester.open("GET", "receipt.php?receipt=" + this.value);
requester.send(null);
return true;
}
Puede que reconozcas algo de la sintaxis de la primera parte de este artículo, a saber, la estructura bifurcada de try/catch, y open() y send() métodos que controlan el objeto de XMLHttpRequest.
Lo primero que realiza la declaración es comprobar si un objeto XMLHttpRequest ya existe y actualmente esta corriendo; si esto es así, se aborta esa conexión. Esto asegura que un número de peticiones XMLHttpRequest que están en conflicto no funcionen simultáneamente, pues obstruiría la red. La función continúa posteriormente, creando un nuevo objeto XMLHttpRequest y abriendo una conexión al script de validación del lado del servidor, receipt.php.
En receipt.php, se comprueba el recibo de la variable CGI y si su valor es "1234567", algunos datos XML son devueltos; de otra manera, una secuencia de texto simple de "empty" es devuelta, indicando que el número de recibo es inválido:
if ($receipt == "1234567")
{
header("Content-type: text/xml");
$filePointer = fopen("example.xml", "r");
$exampleXML = fread($filePointer, filesize("example.xml"));
fclose($filePointer);
print($exampleXML);
}
else
{
header("Content-type: text/plain");
print("empty");
}
Los valores y datos hard-coded se han utilizado en este ejemplo para simplificar el código, pero en el mundo real, este script PHP comprobaría el número del recibo con una base de datos, y devolvería los datos apropiados para ese número.
Observa que si el número del recibo es inválido, el content-type header enviado es "text/plain". Esto simplifica en algo el proceso de impresión del mensaje, pero esto también quiere decir que, en el lado del cliente, la propiedad responseXML del objeto XMLHttpRequest no contendrá cualquier cosa. Como tal, debes siempre estar enterado de lo que devuelven tus escripts del lado del servidor, y vigilar responseXML o responseText apropiadamente.
Así como llamar al script del lado del servidor, onchangeReceipt() también asigna onreadystatechangeReceipt() supervisar el estado de la conexión vía el evento onreadystatechange, y esta es la función que determina cuando la conexión termina y la acción remota debe ser tomada. Para hacer esto, utilizamos la condición anidada readyState/status discutida previamente:
function onreadystatechangeReceipt()
{
/* If XMLHR object has finished retrieving the data */
if (requester.readyState == 4)
{
/* If the data was retrieved successfully */
if (requester.status == 200)
{
writeDetails();
}
/* IE returns a status code of 0 on some occasions, so ignore this case */
else if (requester.status != 0)
{
alert("There was an error while retrieving the URL: " + requester.statusText);
}
}
return true;
}
Cuando se retorna un código de estado correcto, writeDetails() es llamada. Es esta función, lo que parsen los datos devueltos y determina que hacer a la página Web:
function writeDetails()
{
var receipt = document.getElementById("receipt");
if (requester.responseText.charAt(0) == "<")
{
var email = document.getElementById("email");
var name = document.getElementById("name");
receipt.valid = true;
email.value = requester.responseXML.getElementsByTagName("email")[0].
childNodes[0].nodeValue;
}
else
{
receipt.valid = false;
}
return true;
}
Esta función, en primer lugar comprueba la propiedad responseText del objeto XMLHttpRequest, para ver si el número del recibo es válido o no. Si es válido, los datos estarán en formato de XML y su primer carácter será un ángulo de abertura (<), de lo contrario, será una secuencia llana. En cada caso, la propiedad extendida válida se fija apropiadamente en el campo del número del recibo. Además, si el número del recibo es válido, los datos extras se agregan al campo del email, siendo analizados por la propiedad responseXML del objeto XMLHttpRequest.
La ejecución de writeDetails() marca el final del proceso de scripting remoto para la validación del número del recibo. Con la propiedad válida en el campo, el navegador sabe si los datos son válidos o no, y puede alertar a usuarios de cualquier error cuando ellos intenten enviar el formulario:
orderForm.onsubmit = checkForm;
function checkForm()
{
if (!receipt.valid)
{
receipt.focus();
alert("Please enter a valid receipt number.");
return false;
}
...
Si hay un error en el formulario, un diálogo alert() aparecerá cuando el botón del envío se presiona, pidiendo que el usuario corrija el error antes de que el formulario sea enviado:
checkForm() también maneja el envío de los datos del formulario vía scripting remoto (sin embargo, en realidad, el envío normal del formulario es suficiente para una aplicación como esta). El scripting remoto para el envío de datos utiliza el mismo código que utilizamos para la validación, pero un distinto script del lado del servidor se provee para procesar los datos, y en lugar de onreadystatechangeReceipt() siendo llamado una vez que la conexión haya acabado, onreadystatechangeForm() es lamado.
onreadystatechangeForm() disparadores sentForm() para rescribir la página Web e informar al usuario que el ecard fue enviado con o sin éxito, dependiendo de los datos devueltos por el servidor:
function sentForm()
{
var body = document.getElementsByTagName("body")[0];
body.innerHTML = "<h1>Send someone an e-card from ExampleCo!</h1>";
if (formRequester.responseText == "success")
{
body.innerHTML += "<h1>Send someone an e-card from ExampleCo!</h1><p>Your ExampleCo e-card has been sent!</p>";
}
else
{
body.innerHTML += "<p>There was an error while sending your ExampleCo e-card.</p>";
}
return true;
}
Esto cambia el formulario inicial presentado al usuario, e inserta un mensaje final de estado:
Mientras que esta aplicación casi rescribe la página entera, es fácil ver cómo las partes específicas del DOM se podrían cambiar usando scripting remoto, lo que permitiría separar partes de una interfaz de aplicación independientemente de la página Web en si misma.
Puedes continuar con la tercera parte de este excelente artículo en el siguiente enlace: AJAX: Usabilidad Interactiva con Código Remoto (3ra Parte)
