Pinien

Lesson Plan - Lesson exmaple

2012-02-03T20:01:00.001-03:00

Lesson Plan - para shaerar

2012-01-19T21:55:00.001-03:00

Actualización de Medidor de progreso de subida de archivos en Ajax

2007-03-07T17:15:00.000-03:00

Este artículo es la traducción del este PHP AJAX File Upload Progress Meter Updates

Durante el fin de semana mi código de medidor de subida de archivos tuvo mucho tráfico. Parece que está en la lista de populares de del.icio.us y tambien está obteniendo un montón de votos en digg. Para celebrar esto actualicé el código.
La nueva característica mas importante es que devuelve información sin tener que parchear PHP. Ahora la versión parcheada te da mas información como velocidad de subida y tiempo estimado de finalización. Pero igual damos devolución al usuario sin usarlo.
También creé algunas páginas wiki para empezar el proceso de documentación
Acá están los demos:
Con el Parche y la extensión
Sin el parche
Para tener la velocidad de subida vas a necesitar descargar e instalar el parche y extensión PHP Upload Progress.

Si queres usar el codigo necesitas:
Instalar HTML_AJAX (pear install HTML_AJAX-alpha)
Descargar PAFUPMU e instalarlo en algún lugar accesible.
Agregar el código a tu página usando demo.php como un ejemplo.

La forma básica en que trabaja el código es: tomamos un formulario que contiene una subida de archivo y un aceptar con un objetivo (target) en un iframe oculto. Hacer esto permite que la subida pase en el fondo. Entonces consultamos al servidor en lapsos regulares (digamos intervalos de 2 segundos) preguntando para actualizar el estado. Si tenés el parche+extensión instalado te da la velocidad de subida del archivo, etc. Si no tenés la extensión paramos de hacer llamadas AJAX y solo animamos la barra de estado hasta que la subida termine en el iframe y nos diga que terminamos.
En demo.php nos encargamos de generar la página vigente y manejamos la subida en la misma página. Entonces empezamos gestionado la actualización.

<?php
include ‘UploadProgressMeter.class.php’;
$fileWidget = new UploadProgressMeter();
if ($fileWidget->uploadComplete()) {
// output javascript to the iframe to send a final status to the main window
// this will catch error conditions
echo $fileWidget->finalStatus();
// move the file(s) where they need to go
exit;
}
?>

Este código solo funciona cuando estas subiendo por eso no veras nunca una salida de este. Esto puede hacer problemático el seguimiento de errores. Por otro lado esto se puede resolver haciendo el iframe no oculto.
Luego montas el Javascript necesario, primero HTML_AJAX y después los subidores JS.

demoserver.php está incluido en la fuente, puede ser que quieras nombrarlo de otra manera si realmente usas este código.Es solo una página usando HTML_AJAX_Server para registrar la clase UploadProgressMeterStatus.
También necesitás algo de CSS para darle estilo a la barra de progreso. Lo único importante es que .progressBar y . progressBar.bar estén posicionadas relativamente.

.progressBar {
position: relative;
padding: 2px;
width: 300px;
height: 40px;
font-size: 14px;
}
.progressBar .background {
border: solid 1px black;
width: 270px;
height: 20px;
}
.progressBar .bar {
position: relative;
background-color: blue;
width: 0px;
height: 20px;
}

Finalmente termina las cosas construyendo un formulario. Fijate que podés incluir otros elementos en el formulario, pero si necesitan producir una salida vas a tenés que manejar rellamadas en la pagina padre desde la salida del iframe.

<form action="demo.php" enctype="multipart/form-data" method="post" <?php echo $fileWidget->renderFormExtra(); ?>>
<?php echo $fileWidget->renderHidden(); ?>
<label>Select File: render(); ?>
< ?php echo $fileWidget->renderProgressBar(); ?>
</div>
</form>

Progreso del upload de un archivo en AJAX

2007-03-06T15:00:00.000-03:00

Este artículo es la traducción del este AJAX File upload Progress

El ejemplo de como usar la versión mas nueva está disponible en otro post.
Actualización
Hay una nueva versión de este código que sigue la misma premisa pero usa HTML_AJAX en vez de JPspan.
Podes ver el nuevo demo y ver el código en websvn.
Notar también que el servidor no está configurado para aceptar archivos mayores de 8 Mb. Si es así el script va a fallar.
También estoy buscando a alguien que me ayude a mejorar el manejo de errores, si estas interesado en participar y hacer algunas actualizaciones de código nuevo házmelo saber.

Sigue el artículo Original

Un par de días atrás, encontré un proyecto interesante de ruby on rails. Usa Ajax para actualizar una barra de progreso mientras sube un archivo. Este truco es un parche para rails para obtener el estado de subida y hacer la subida en un iframe para que la pagina principal siga activa.
Entonces para implementar esto solo tenía que encontrar el parche que provee el estado de la subida en PHP y luego implementarlo en mi pequeño iframe accesorio de subidas.
Encontré el código PHP con un poco de trabajo en Google: Barra de progreso de subida
Primero necesitas instalar el parche y la extensión, las instrucciones incluidas son fáciles de seguir. El único problema que encontré es que hay que configurar: upload_progress_meter.store_method = “file” en mi php.ini en primera instancia antes de probar los scripts.
También tuve un problema con JPSpan, si estas teniendo problemas de red el llamado de estado puede tomar mas de un segundo y vas a tener un alerta de error de llamada en progreso. Esto puede ser resuelto con la versión actual de JPSpan pero me gustaría ver alguna api agregada para ayudar. Los objetos con Proxi necesitan algún tipo de llamada en progreso para hacer un arreglo fácil.
Un ítem notable es que la extensión provee información de la transferencia total de manera que solo se implementa una barra por formulario sin importar cuantos archivos tenga. El código Javascript esta programado para varios formularios en una página y que suban al mismo tiempo, pero no ha sido testeado.
Acá está el demo que estabas esperado, para la mayoría de la conexiones un archivo de 250k va a ser suficiente para apreciar algo además de conectar y completar.
Además si alguno tiene el tiempo y las habilidades para revisar el parche php y ver que necesitaría para estar integrado,por favor haganmelo saber. No se nada del autor por eso no sé por que no está integrado pero parece medio loco tener un parche de 3k tan útil solamente disponible para aquellos que estar dispuestos a parchear.

Detalle del código
EL flujo básico sucede así:
Muestra una página con un formulario:
Esta página tiene un iframe oculto, un div de progreso oculto, y algun código javascrip extra.
Selección del archivo para subir y acepto el fomulario:
El formulario tiene un objetivo (target) en el iframe oculto, por esto aún cuando icono indicador de actividad del navegador empiece funcionar, la pagina principal no va a tener nuevo contenido cuando el upload haya terminado.
El evento onclick del formulario dispara una función determinada:
La función encuentra el div de progreso y lo muestra, también registra una función para actualizar el estado cada segundo.
La función actualización dispara cada segundo:
Esta función controla un contador para ver si hay algun div mas para actualizar, si el contador es cero detiene la función actualización desde el disparo otra vez.
La función crea un objeto proxy remoto para la clase php UploadProgressMeterStatus si aún no ha sido creado.
La función llama al método get_status en el objeto proxy con un lista de todos los divs de progreso y una de los UPLOAD_IDENTIFIER que necesitamos los estados.
La función existe.
El método get-status en la clase de php es llamado.
El método llama a upload_progress_meter_get_info() para cada uno pasado en el indentificador, la información es formateada a un porcentaje y un mensaje que es devuelto.
La funcion de rellamada para get_status se llama cuando laclases PHP devuelve información.
La rellamada actualiza el div de progreso.
Si estubiera al 100% decrementamos nuestro contador de div de progreso y lo removemos de la lista de divs para ser actualizados.
El iframe puede tambien cargar una página una vez que la carga haya terminado, actualmente no hace nada.
Código de ejemplo
Este es realmente el único código PHP interesante en el proyecto, y no tan interesante. Cuando tenés instalada la extensión de medidor de progreso de subida todo formulario que este haciendo una subida de archivo y tenga una barra oculta que se llame UPLOAD_IDENTIFIER puede ser seguido. El identificador tiene que ser pasado en la función upload_progress_meter_get_infopor eso tenés que hacer el seguimiento del mismo del lado de Javascript. Acá solo pasamos eso identificadores, hacemos un grupo de ellos en el array de resultado y devolvemos los resultados. Notar que el array devuelto no esta documentado en ningún lado por lo que este código y el código en el ejemplo de php provisto con la extensión es el mejor lugar para empezar si querés.

?php

/**
* Obtener el estado de todas las subidas que se pasen.
*/
function get_status($ids) {
$ret = array();
foreach($ids as $id => $upId) {
$ret[$id] = new stdClass();

$tmp = upload_progress_meter_get_info($upId);
if (!is_array($tmp)) {
$ret[$id]->message = “Complete”;
$ret[$id]->percent = “100″;
break;
}

if ($tmp[‘bytes_total’] < percent =" 100;" percent =" round($tmp[‘bytes_uploaded’]" percent ="=">message = “Complete”;
}

$eta = sprintf(“%02d:%02d”, $tmp[‘est_sec’] / 60, $tmp[‘est_sec’] % 60 );
$speed = $this->_formatBytes($tmp[’speed_average’]);
$current = $this->_formatBytes($tmp[‘bytes_uploaded’]);
$total = $this->_formatBytes($tmp[‘bytes_total’]);

$ret[$id]->message = “$eta left (at $speed/sec) $current/$total($percent%)”;
$ret[$id]->percent = $percent;
}
return $ret;
}
?>

En el lado de JavaScript hay un poco mas de código, pero no es para nada complejo.Este código es usado para mostrar la barra de progreso y darle algunos valores iniciales. Las cosas mas importantes para resaltar son que hay agregado un método de actualización al div, este es un lindo truco por que permite la extensión en tiempo de ejecución de los objetos en DOM, y va a hacer actualizar las cosas agradable y fácil en otras funciones. También agregamos un método getFirstDivByClass al div, hago esto para no tener tantos div para seguir, las clases solo tienen que ser únicas dentro de la barra de proceso para que ande y eso es mucho mas fácil de lograr

/**
* Muestra una barra de progreso y la establece a 0
*/
function UploadProgressMeter_EnableProgress(progress_id) {
var progress = document.getElementById(progress_id);
progress.style.display = ‘block’;
progress.percent = 0;
progress.message = "Connecting";

progress.update = function() { this.getFirstDivByClass(‘bar’).style.width = this.percent+‘%’; this.getFirstDivByClass(‘message’).innerHTML = this. message; }

progress.getFirstDivByClass = function(className) {
var nodes = this.getElementsByTagName(‘div’);
for(var i = 0; i < classname ="="">

El código siguiente llama a un proxy remoto y crea una función de rellamada para gestionar el resultado. Hay un área donde se pueden hacer mejoras. Primero debería haber un control de si hay actualmente una llamada en progreso. Luego, sería inteligente llamar al servidor menos (especialmente en archivos grandes) y solo generar las estadísticas del índice de descarga actual.Esto va a agregar un poco de complejidad pero permitiría a la barra de progreso actualizar suavemente y permitiría que las llamadas al servidor bajar a una vez cada 5 o 10 segundos
Si no haces mucha programación javascript no vale la pena el uso de for(var prop in result) en delete UploadProgressMeter_active[prop];
for(var prop in result) es como iteras en las propiedades de un objeto, esto te permite usarlas como arreglos asociativos (solo mira los métodos en los objetos ya que vas a iterar en ellos también).
delete UploadProgressMeter_active[prop] es el equivalente de unset($array[’key’]);

/**
* Actualizar las barras de progreso de todas las barras vigentes
*/
function UploadProgressMeter_Update() {
if (UploadProgressMeter_count == 0) {
clearInterval(UploadProgressMeter_intervalId);
UploadProgressMeter_intervalId = false;
return;
}

if (UploadProgressMeter_remote == false) {
var callback = {
get_status: function(result) {
for(var prop in result) {
if (prop != "toString") {
document.getElementById(prop).percent = result[prop].percent;
document.getElementById(prop).message = result[prop].message;
document.getElementById(prop).update();

if (document.getElementById(prop).percent == 100) {
UploadProgressMeter_count–;
delete UploadProgressMeter_active[prop];
}
}
}
}
}
UploadProgressMeter_remote = new uploadprogressmeterstatus(callback);
}
UploadProgressMeter_remote.get_status(UploadProgressMeter_active);
}

Code List

Tarball

Código principal del coso php

Código del coso de Javascript

Página demo html/php

Página del servidor Demo JPSpan

Actualizaciones
Te habras dado cuenta que el demo dejo de andar un par de veces. Esto está relacionado con dos cosas y hay cosas que puede ser que quiera pensar si vas a usar el parche. Primero escribe archibos tmp y falla sileciosamente si no existe más (scripts que limpian los tmp). Segundo, esta en my servidor php5 que tiene algunos usuarios que estan presionando para que me actualice a php 5.1 beta y me olvide de reparchear. Reparchear no fue un gran problema aunque tube que mover donde una funcion fue declarada para obtener la extensión para compilar en gcc 4 (me actualice a fedora core 4 también)
De todos modos el demo está trabajando y debería seguir trabajando siempre y cuando me acuerde de reparchear con cada actualización.
Nueva versión
Este código ha sido actualizado para trabajar con HTML_AJAX y para manejar mejor las condiciones de error. No he hecho un lanzamiento oficial paro podes tomarlo del svn.
Ver en: http://svn.bluga.net/HTML_AJAX/UploadProgressMeter/trunk/
O usar websvn para obtener un tarball: http://websvn.bluga.net/wsvn/HTML_AJAX/UploadProgressMeter/trunk/?rev=0&sc=0
También si estas interesado en ayudar con la medición de progreso de subida, haganmelo saber.

Mootools Introducción/Tutorial - Native

2007-01-13T11:22:00.000-03:00

El grupo de scripts Native son extensiones básicas de los objetos por defecto en javascript (actualmente Mootools tiene código nativo para Array, Element, Function y String) Esos archivos modifican la manera en que esos elementos y toda instancia de ellos trabajan. Como es posible crear arrays o strings antes de que este código se ejecute, tienen típicamente un significado por el cual aplican estas funciones a los strings existentes. Por ejemplo, $A(myArray) solo te devuelve myArray con todas las extensiones aplicadas.
Acá hay un resumen de las funciones disponibles para esos objetos; la mayoría de ellos pueden ser ejecutados haciendo click "ejecuta este código".

String.js - Extensiones String, Numer.toInt()

Acá esta la página de documentación de String.js.

String.test()
JavaScript:
"I like cookies".test("cookie"); // devuelve ["cookie"]

//ignora la distinción de mayúsculas y minúsculas
"I like cookies".test("COOKIE", "i")

JavaScript:
//ignora la distinción de mayúsculas y minúsculas
"I like cookies because cookies are good".test("COOKIE", "ig");

JavaScript:
//no devuelve nada
"I like cookies".test("cake");

JavaScript:
//este es un ejemplo de como probablemente lo usarias en realidad
if("I like cookies".test("cake")) alert ('you like cake');
else alert("you don't like cake (what's wrong with you?)");

String.toInt()
JavaScript:
"10".toInt(); // el valor es 10

JavaScript:
"10px".toInt(); // el velor es 10

JavaScript:
"-10".toInt(); // el valor es -10

JavaScript:
"px10".toInt(); // no devuelve nada

String.camelCase()
JavaScript:
"I-like-cookies".camelCase(); //"ILikeCookies"

String.capitalize()
JavaScript:
"i like cookies".capitalize(); //"I Like Cookies"

String.trim()
JavaScript:
" i like cookies ".trim() //"i like cookies"

String.clean()
hace lo mismo que trim y ademas elimina todos los doble espacios del string
JavaScript:
" i like cookies \n\n".clean() //"i like cookies"

String.rgbToHex()
JavaScript:
"rgb(17,34,51)".rgbToHex(); //"#112233"

JavaScript:
"rgba(17,34,51,0)".rgbToHex(); //"transparent"

JavaScript:
"rgb(17,34,51)".rgbToHex(true); //[11,22,33]

String.hexToRgb()
JavaScript:
"#112233".hexToRgb(); //"rgb(17,34,51)"

Number.toInt()
Number.toInt() solo devuelve el número; útil porque toInt debe trabajar en ambas Strings y Números.

Array.js

Acá está la documentación de Array.js
Array.each()
Array.each() itera en el Array ejecutando la funcion especificada para cada ítem del array. La funcion anonymous pude pasar dos argumentos (opcionales) - el ítem y el índice:

["one", "two", "three"].each(function(number){
alert(number);
});

["one", "two", "three"].each(function(number, index){
if(index == 0) alert(number); //solo vamos a mostrar el primero
});

Array.copy()
Copia el array y lo devuelve.

var letters = ["a","b","c"];
var copy = ["a","b","c"].copy();
alert(copy);

Array.remove()

JavaScript:
["1","2","3"].remove("2") // ["1","3"];

Array.test()

JavaScript:
["a","b","c"].test("a"); // true

JavaScript:
["a","b","c"].test("d"); // false

Array.extend()

JavaScript:
var Animals = ['Cat', 'Dog', 'Coala'];
Animals.extend(['Lizard']); //Animals is now: ['Cat', 'Dog', 'Coala', 'Lizard'];

Array.associate()

JavaScript:
var Animals = ['Cat', 'Dog', 'Bird', 'Lizard'];
var Speech = ['Meow', 'Bark', 'Chirp', 'Mute'];
var Speeches = Animals.associate(speech);
//Speeches['Meow'] is now Cat.
//Speeches['Bark'] is now Dog.
//...

$A()
$A() aplica esas funciones a cualquier objeto iterable. Ejemplo:

JavaScript:
function myFunction(){
$A(arguments).each(argument, function(){
alert(argument);
});
};
//the above will alert all the arguments passed to the function myFunction.

Function.js

Acá está la documentación de Function.js.
Function.pass(arguments, bind(optional))

JavaScript:
//syntax: Function.pass(arguments, bind)
//bind es opcional; mas sobre bind mas tarde
//ejemplo: myFunction.pass([arg1, arg2], myElement);
function say(msg){
alert(msg);
};
say.pass('hello world')();

Te preguntarás porqué hacer esto, pero vas a ver el porqué en ejemplos mas adelante. Basicamente, no siempre queres ejecutar una funcion inmediatamente, y sin algo como el método .pass() no tenes manera de pasar variables a esa funcion sin ejecutarla. myFunction(value) ejecuta muyFunction. myFunction.pass(value) configura myFunction para poder ejecutarla mas tarde.
Vamos a decir que tenés un efecto que va a hacer que algo se desvanezca. Cuando está hecho, queres ejecutar un callback de algun orden. Tu efecto tiene una opción para que le entregues una función para que la ejecute cuando termine, pero necesitas pasarle a esa función algunas variables. Si haces algo como:"onComplete: myFunction(value)" vas a ejecutar tu función inmediatamente y onComplete sera equivalente a lo que sea devuelto, lo cual no es lo que querés. Si en cambio haces "onComplete: myFunction.pass(value)" obtendras lo que querìas. myFunction.pass(value) devuelve una instancia de esa función con el parámetro establecido, entonces cuando ejecutes onComplete() va a estar ejecutando realmente myFunction(value)

Function.bind(object)
La palabra reservada "this" dentro de un objeto (como una función) refiere a la instancia de ese objeto. Es realmente muy útil para un montón de cosas, no solo las que están referidas a otras funciones en el mismo objeto o estado de cierta variable. El problema es que puede ser que seas autor de la funcionalidad que necesita poder referir a variables en el objeto que lo está llamando. Abajo hay un ejemplo simple de esto, pero cuando escribes clases y funciones más complejas vas a encontrar que esta habilidad para definir que "this" es, en un contexto dado, una necesidad.
Este ejemplo debe cambiar este párrafo a que tengo un borde alrededor de él.

JavaScript:
function myFunction(){
this.setStyle('border', '1px solid black');
//notar que 'this' acá refiere myFunction, no a un elemento
//vamos a necesitar unir esta funcion con el elemento que queremos alterar
};
//Unir el elemento que quiero aplicar el efecto con la función
//Notar que una función es devuelta, no ejecutada
var myBoundFunction = myFunction.bind($('bindExample'));
//ejecutar esa nueva función con el objeto bound
myBoundFunction();

Function.bindAsEventListener();
Una función con el parámetro bind como su "this" y como un evento de argumento pre-pasado o window.event, dependiendo del navegador.

JavaScript:
function myFunction(event){
alert(event.clientx) //devuelve las coordenadas del mouse
};
myElement.onclick = myFunction.bindAsEventListener(myElement);

Function.delay(milliseconds, bind(optional))
Si, puedes establecer demoras con setTimeout, pero a veces es enrrollado y complicado. Adicionalmente, la demora te permite unir un elemento con la función que va a se demorada
El ejemplo que sigue debe dibujar un borde alrededor de este párrafo después de un segundo de espera.

JavaScript:
function myFunction(){
this.setStyle('border', '1px solid black');
};
myFunction.delay(500, $('delayExample'));

Acá hay un gran ejemplo de vinculación. Si el elemento fuera un argumento para la función, no podría llamar la función con un argumento sin ejecutarla. Este tipo de sintaxis no funcionaría:

myFunction($('delayExample')).delay(500);

...no podría funcionar, porque ejecutarías la función inmediatamente y .delay() intentaría ejecutarse como un método de lo que haya sido devuelto.
Podrías hacer esto sin embargo:
myFunction.pass($('delayExample')).delay(500);
Está también .periodical(), que periódicamente ejecuta tu función

There's also .periodical(), which repeatedly executes your function.
La clase cadena (chain)
Encadenar es una manera bastante inteligente de establecer una lista de funciones que quieras ejecutar en un orden dado sin ejecutarlas todavía. Luego, cada vez que llames el método .callChain() la próxima función de ejecutará.

JavaScript:
var x = new Chain();
var one = function(){alert('1')};
var two = function(){alert('2')};
x.chain(one);
x.chain(two);
x.callChain();
x.callChain.delay(2000);

$clear() - liberando esperas

JavaScript:
var myTimer = (function() {alert('1 second!');}).delay(1000);
//espera 5 segundos y ejecuta mi función
myTimer = $clear(myTimer); //no importa

$type() - Obtener el tipo de un elemento
$type devuelve el tipo de un objeto ("function" o "string", etc.) o nada si el objeto es nulo (o una cadena vacía). (Nota: esto está cambiando en la próxima versión de mootools; si le das a $type un boolean= false en mootools versión 84 vas a obtener un falso, no un "boolean"; esto está cambiando para devolver el tipo real del objeto, y solo devolver falso si el objeto es nulo o indefinido, por esto usar con precaución).

JavaScript:
$type('hi'); //"string"

JavaScript:
$type(function(){});//"function"

JavaScript:
$type({});//"object"

JavaScript:
$type([]);//"array"

JavaScript:
var x = null;
$type(x);//nothing returned

Element.js

Acá está la documentación para Elements.js.
El objeto Element consigue mucho amor en Mootools. La mayoría de las funciones en el objeto Element son bastante auto-explicativas. Element.getTag() hace lo que piensas que podría hacer. Element.remove() no tiene sorpresas. Acá hay algunos ejemplos de las funciones más útiles y menos obvias, pero realmente deberías leer la página de documentación de Element.js para el detalle completo.
Element.initialize()
Este solo crea un nuevo objeto elemento - lo mismo que document.createElement, pero también aplica las extensiones de Mootools a ese elemento.

JavaScript:
var img = new Element("img");

$()
Cansado de escribir "document.getElementById('blah')"? no hay problema. Esto también aplica todas esas extensiones de Element al objeto.

JavaScript:
$('getElementByIdExample');

Element.injectInside, Element.injectBefore, Element.injectAfter
Mucho más de lo que parece. Inyecta el elemento relativo a el que sea pasado como argumento.

HTML:
<div id="myElement"></div>
<div id="mySecondElement"></div>
<script>$('mySecondElement').injectBefore('myElement');</script>
resulting html:
<div id="mySecondElement"></div>
<div id="myElement"></div>

injectInside usa appendChild en el elemento provisto:

html:
<div id="myElement"></div>
<div id="mySecondElement"></div>
<script>$('mySecondElement').injectInside('myElement');</script>
resulting html:
<div id="myElement"><div id="mySecondElement"></div></div>

Element.adopt
Este es tal como injectInside, pero al revés (añande el elemento provisto al que se aplica):

HTML:
<div id="myElement"></div>
<div id="mySecondElement"></div>
<script>$('mySecondElement').adopt('myElement');</script>
resulting html:
<div id="mySecondElement"><div id="myElement"></div></div>

Element.replaceWith

JavaScript:
$('myOldElement').replaceWith($('myNewElement'));

$('myOldElement') no está mas, y $('myNewElement') está en su lugar.
Element.appendText

HTML:
<div id="myElement">hey</div>
<script>
$('myElement').appendText(' howdy');
//myElement innerHTML es ahora "hey howdy"
</script>

Element.add/removeClass/hasClass/toggleClass
Estos hacen bastante más de que aparentan hacer.

Este parrafo tiene id=cssClassesExample para el ejemplo siguiente.

JavaScript:
//tiene el párrafo de arriba el className blue?
$('cssClassesExample').hasClassName('blue');

JavaScript:
//se lo agregamos
$('cssClassesExample').addClassName('blue');

JavaScript:
//ahora lo borramos
$('cssClassesExample').removeClassName('blue');

JavaScript:
//ahora vamos a prenderlo y a apagarlo
$('cssClassesExample').toggleClass('blue');

Element.getStyle, Element.setStyle, Element.setStyles
Bastante directo:
Este párrafo tiene id = getStyleExample para el ejemplo siguiente.

JavaScript:
$('getStyleExample').getStyle('width'); //returns something like "528px"

JavaScript:
$('getStyleExample').getStyle('width').toInt(); //returns 528 (an integer)

setStyle te permite establecer una única propiedad css:

JavaScript:
$('setStyleExample').setStyle('border', '1px solid black');

setStyles tiene una sintaxis levemente diferente y te permite establecer todas las que quieras:

JavaScript:
$('setStylesExample').setStyles({
'border':'1px solid yellow',
'background':'#666',
'color':'#fff'
});

Element.setProperty, setProperties
Trabaja bastante similar a setStyle(s) excepto que puedes establecer las propiedades de un elemento:

JavaScript:
var img = new Element('img');
img.setProperty('src', http://clientside.cnet.com/wp-content/themes/clientside/art/logo.gif');
img.setProperty('id', 'logoExample');
img.injectInside($('setPropertiesExample'));

Vamos a asignar algunas propiedades más:

JavaScript:
$('logoExample').setProperties({
'alt':'clientside',
'title':'clientside'
});

Element.getProperty()

JavaScript:
$('logoExample').getProperty('src');//gets the img url

Element.getTop(), getLeft()
Este devuelve el offset de la parte de arriba del elemento y la parte de arriba de la ventana (o la izquierda del elemento y la izquierda de la ventana)
Este párrafo se usa en el ejemplo siguiente.

JavaScript:
$('topAndLeftExample').getTop() //returns an integer

JavaScript:
$('topAndLeftExample').getLeft() //returns an integer

Element.getValue()
Devuelve el valor de un campo de entrada de un formulario. Ejemplo:

JavaScript:
$('getValueInputExample').getValue() //devuelve algun valor

JavaScript:
$('getValueSelectExample').getValue() //devuelve 'value 1'

Element.setHTML()
Vamos a cambiar este contenido...

JavaScript:
$('setHTMLExample').setHTML('ves? cambió!');

Te preguntaras porqué usar esto o algo como getProperty cuando javascript tiene métodos para hace es el mismo; estamos solo cambiando una sintaxis por otra. Podes tan fácilmente hacer:

JavaScript:
$('setHTMLExample').innerHTML = 'ves? cambió!';

entonces, por que hacerlo? Bueno, haciendo esta función disponible podes hacer cosas como .delay() y .pass() en aplicaciones mas complejas. Tambien permite encadenar cosas juntas como:

JavaScript:
$('myExample').setHTML('example').addClass('something').removeClass('somethingElse').addEvent(....) etc.

Element.getTag()

JavaScript:
$('logoExample').getTag() // returns 'img'

Element.setOpacity
Opacity toma un valor entre cero (transparente y 1 (opaco)

JavaScript:
$('setOpacityExample').setOpacity(0); //ahora no lo ves

JavaScript:
$('setOpacityExample').setOpacity(.5); //se ve a medias

JavaScript:
$('setOpacityExample').setOpacity(1); //se ve 100%

Element.addEvent
Aquellos que estén familiarizados con el objeto Event de Prototype.js van a reconocer este concepto; solo hay una diferencia de sintaxis. notar que el nombre del evento que le des ("click" o "mouseover") no tiene el prefijo "on".
Este párrafo se usa en el ejemplo siguiente

JavaScript:
$('addEventExample').addEvent('click', function() {
alert('click!');
});

Porque usar esto en ves de hacer $('addEventExample').onclick = alert('click');? Bueno, usar capturadores de eventos como este te permite tener mas de uno. si haces .onclick=myFunction podes tener solo un evento esperando ese click. Click puede no ser un gran ejemplo, pero ciertamente algo como window.onload vas a querer tener numerosos eventos monitoreando.
También podes usar Element.removeEvent() para remover un capturador de evento
Element.getNext, getPrevious, getLast
Todos ellos obtiene elementos vecinos relativos al que apliques este método.
Este es el HTML del ejemplo siguiente:

HTML:
<ul id="getSiblingExamples">
<li id="firstLI">first</li>
<li id="secondLI">second</li>
<li id="thirdLI">third</li>
</ul>

* first
* second
* third

JavaScript:
$('secondLI').getPrevious() //obtiene el primer elemento de la lista

JavaScript:
$('secondLI').getNext() //obtiene el tercer elemento

$('getSiblingExamples').getLast() //obtiene el tercer elemento

$Element(DOMelement, function, arguments) - funciones ayuda.
Aplica un método con el pasda en argumentos para el pasado en elemento. Útil si no querés extender el elemento.

JavaScript:
$Element(el, 'hasClass', className) //Verdadero o falso

Mootools Introducción/Tutorial - moo.js

2007-01-11T11:12:00.000-03:00

El artículo original en inglés se encuentra acá, y esta es una traducción libre, de aficionado, con los fines de practicar ingles y aprender mootools...

Lo que sigue es un tutorial instructivo de la librería mootools. La mayoría del código de los ejemplos de código te permitirán ejecutarlos haciendo click en el link "ejecuta este código" que está abajo del ejemplo. Haciendo click ahí te mostrará el código y el resultado en el plugin Firebug debugging de Firefox. Vas a necesitar tener instalado ese plugin ver algún resultado de la mayoría de los ejemplos de código.
Nota: Este ejemplo parece que solo funciona en Firefox por el momento; Lo voy a arreglar pronto.

Creación de clases

Acá esta la página de documentación de moo.js
Mootools contiene un sistema de creación de Clases y herencias robusto. Crear una nueva clase es, de hecho, muy fácil.
Clases vs funciones
Las clases te permiten:
-reutilizar y modificar código sin romper cosas que dependan de él.
-Crear un objeto autómata/independiente/dinámico (statefull) que pueda guardar información en su propio alcance.
-Crear aplicaciones más robustas a través del desarrollo de clases pequeñas, reutilizables y extendibles.
Las funciones autónomas te permiten:
-Crear colecciones de ejecuciones que deban ocurrir juntas
-Crear atajos a otras funciones que tengan una sintaxis larga
-Ejecutar algo, de hecho.
Las funciones son usadas moderadamente con mootools porque las clases son mucho mas poderosas. Si empiezas con una clase y tratas de mantener las cosas genéricas, y piensas en lo que escribes para que sea reutilizable, te vas a encontrar luego extendiendo algo que ya habías escrito y ahorrando un montón de tiempo y creando una solución mas robusta para tus problemas. Otros podrán utilizarla también.
El mismo Mootools es un gran ejemplo de como usar clases te permite crear aplicaciones complejas con menos código. El fundamento o base de mootools es el objeto clase. Casi toda otra parte de javascript en la librería extiende este objeto para crear funcionalidades mas complejas.
Una clase simple
Acá hay un una clase simple usando la sintaxis de mootools:

Javascript:
var Animal= new class ({
initialize: function(options){
this.options=options;
}
});

Animal ahora es una clase base sin funcionalidad concreta. Podemos extenderla, algo que vamos a hacer en la próxima sección. La sección "inicial" va a ser ejecutada cuando un nuevo objeto animal es instanciado, y los argumentos pasados al constructor van a ser guardados como ".options" del nuevo objeto, como esto:

Javascript:
var Gato = new animal({color: "negro"});

Arriba tenemos una instancia de la clase Animal y establecimos el color de este Animal a "negro"

Javascript:
alert(Gato.options.color); //-> Muestra "Negro"

Esto por si mismo no es muy interesante, pero cuando empezás a crear clases que heredas una de la otra, o a implementar funcionalidades en la clase base, vas a ver la potencia que tiene.
La cosa que es ilustrada acá es lo autómata/independiente/dinámico del objeto - la parte "this.options". Ahora este objeto puede recordar su estado sin tener que declarar un grupo de variables globales en la parte superior de tu documento solo para guardar información.

Agregar funciones a una clase

Las clases pueden contener funciones dentro de ellas de la misma manera que pueden contener variables (como "this.options"). Ejemplo:

Javascript:
var Animal = new Class({
initialize: function(options){
this.options = options; //Guarda tus opciones
//si las opciones especifican que Animal
//esta dormido cuando lo crean, llama dormir()
if(this.options.dormirAlInicio) this.dormir();
//sino está despierto
else this.depertar();
},
dormir: function() {
this.estaDormido= true;
},
despertar: function(){
this.estaDormido = false;
}
});

Ahora podemos instanciar nuestro animal y mandarlo a dormir o a despertarlo cuando queramos.

Javascript:
var Gato = new Animal({
color: "Negro",
dormidoAlInicio: true
});
//el gatito esta dormido, vamos a despertarlo
Gato.despertar();
alert(Gato.estaDormido);
//-> alerts "falso"

Extender las clases

Las clases pueden ser extendidas para crear funcionalidades mas complejas. En los ejemplos anteriores hemos creado un objeto (Animal) y una instancia de ese objeto (Gato), pero extendiendo la clase base podemos crear funcionalidades mas complejas mientras reutilizamos nuestro código. Ejemplo:

JavaScript:
var Animal = new Class({
initialize: function(options){
this.options = options;
this.estaVivo= true;
}
});
var Mamifero = Animal.extend({
initialize: function(options){
//esto ejecuta la función initialize() en la clase animal
//Vamos a pasar las opciones a la función initialize del padre
this.parent(options);
this.esSangreCaliente = true;
this.tienePelaje = true;
this.produceLeche = true;
},
dormir: function() {
this.estaDormido = true;
},
despertar: function(){
this.estaDormido= false;
}
});
var Raton = Mamifero.extend();
var Gato = Mamifero.extend({
initialize: function(options) {
//llama initialize de Mamifero
//traspasa todas las opciones a
//las clases Mamifero y animal
this.parent(options)
this.tieneGarras = true;
this.tieneCola = true;
this.esCarnivoro = true;
},
casaRaton: function(Raton){
Raton.estaVivo = false;
return Raton;
}
});

Bien, ahora tenemos una clase Animal, una clase Mamifero (que extiende de Animal) y las clases Gato y Raton (que extienden de Mamifero). El código anterior crea las clases pero no ejecuta nada realmente. Entonces, pongamos este código en uso:

JavaScript:
var Kitty = new Gato({
color: "Negro"
});
var Mickey = new Raton({
color: "Negro",
Pantalones: true,
zapatos: true
});
Kitty.casaRaton(Mickey);
alert(Mickey.estaVivo);
//->falso

Separando las cosas en clases de esta manera, en cualquier momento del futuro podemos implementar nuevos tipos de Animales, Mamiferos o tambien diferentes tipos de gatos y ratones. Significa tambien que si encontramos un error, por ejemplo, en la clase Mamifero, arreglarlo en ese lugar implica que no vamos a tener que arreglarlo en todas la instancias de Mamifero.

Implementar Clases

Extender clases te permite tomar una clase base (como Animal mas arriba) y crear una nueva clase con esa como plantilla (como en nuestra clase Mamifero arriba). Esto no altera la clase animal de ninguna manera.
Esto no es siempre lo que buscamos, sin embargo. A veces queres alterar la clase padre en un contexto dado. Digamos, por ejemplo, que estas usando la clase Animal de arriba, pero querés agregarle una función para tu ambiente. Extender la clase Animal para crear algo como AnimalExtended no te sirve por que vas a usar tambien Gato, Raton y Mamifero y no querés reescribirlas.
Aca es donde Class.implement resulta útil. El método implement te permite agregar funcionalidad a la clase, alterando la clase misma. No podes usar la funcion "this.parent()" como si puedes con la extensión, por que no estás creando un hijo - estas modificando la clase. Adicionalmente, si usas el mismo nombre separado como uno que ya exista, lo vas a sobreescribir. Ejemplo:

JavaScript:
//esta es la misma clase Animal de antes
var Animal = new Class({
initialize: function(options){
this.options = options;
this.estaVivo= true;
}
});
//Vamos a cambiarla para agregarle algunas funcionalidades adicionales
Animal.implement({
comer: function() {
if(typeof this.energia == "indefinido") this.energia = 0;
this.energia++;
}
});

Ahora Animal tiene una función llamada comer() que incrementa su valor de energía.
Vamos a decir que luego queremos agregar la habilidad de pasas un valor inicial en options y queremos implementarlo en la clase tambien. Usando implement, si queremos alterar la función comer, vamos a tener que escribirlo todo de nuevo:

JavaScript:
//let's let you pass in a starting value
Animal.implement({
comer: function() {
if(typeof this.energia == "indefinido") {
if(typeof this.options.iniciarEnergia != "indefinido") this.energia = this.options.iniciarEnergia ;
else this.energia = 0;
this.energia++;
}
});

Implement es usado en Mootools mayormente para extender clases que están en el grupo "Nativo" - específicamente String, Array, Function y Element prototype. Esto significa que si tiene este código:

JavaScript:
String.implement({
alert: function() {
alert(this);
}
});

Cualquier string va a heredar esa función:

JavaScript:
"hey howdy!".alert();

De esta manera, Mootools te da un montón de atajos para cosas que a menudo haces a cosas como Strings, Arrays, etc.
Hay otra manera de usar implement que es bastante útil. Podes crear una clase y luego implementarla en otra, tal cual:

JavaScript:
//Estas son las misma clases Mamifero y Gato de arriba
var Gato = Mamifero.extend({
initialize: function() {
this.parent() //llama initialize de Mamifero
this.tieneGarras = true;
this.tieneCola = true;
this.isCarnivoro = true;
},
function: casaRaton(Raton){
raton.estaVivo = false;
return raton;
}
});
var Carnivoro= new Class({
esCarnivoro = true,
energia = 0,
comer: function() {
this.energy++;
}
});
Gato.implement(Carnivoro);

Ahora todos los Gatos que crees, van a tene la funcionalidad definida en Carnivoro. Esto te permite crear porciones de código mas pequeñas que puedan ser agregados donde se necesiten.

Extender Objetos

Tal como en las clases, los objetos pueden ser extendidos. Esto permite combinar dos objetos juntos en la misma manera que los objetos Clase. Para se especifico, las propiedades de un objeto puede ser copiada en otro, tal como Class.implement() Ejemplo:

JavaScript:
var Ciudad= {
tieneEdificios: true,
tieneTrafico: true
};
var SanFrancisco = Object.extend(Ciudad, {
tieneNiebla: true,
numeroDeEdificios: 1000,
Terremoto: function() {
this.numeroDeEdificios= this.numeroDeEdificios/2;
}
});
SanFrancisco.terremoto(); //espero que tengas seguro!!!

Esto es muy similar a las clases pero no tenés la función initialize() que es ejecutada cuando creas algo y hay otras diferencias en las que no quiero profundizar.
Un gran ejemplo de cómo y porqué extender un objeto puede encontrarse en este articulo sobre this.options - valores por defecto establecidas que pueden ser sobreescritos en tus clases.

Object.Native

Object.Native() solamente toma un objeto y hace que su función .extend() haga lo mismo que la función .implement(). Realmente es usado para crear clases prototipo extensibles como String, Array, etc. Ejecutando Object.Native(String) estableces tu ambiente para que te permita extender la funcionalidad básica de Strings. No necesitas usarlo realmente, pero es útil si querés forzar alguna extensión de una clase para modificar tambien la clase base.

Traducción de Artículo de Ajax XXIII

2006-08-11T17:02:00.000-03:00

Dominar Ajax, Parte 5: Manipular el DOM
Usar JavaScript para actualizar tu página web al vuelo.
Nivel: Introductorio

Brett McLaughlin ( brett@oreilly.com), Autor y Editor, O´Reilly y Asociados.
11 Abril 2006

El mes pasado Brett introdujo el Modelo de Objetos de Documento, cuyos elementos trabajan detrás de escena para definir tu página Web. Este mes se sumerge todavía más profundo en el DOM. Aprender como crear, eliminar y cargar las partes de un árbol DOM, y dar el próximo paso para actualizar tus páginas Web al vuelo

Si seguiste mi discución de esta serie del mes pasado, tenes una visión de que sucede cuando un navegador Web muestra una de tus páginas. Como expliqué antes, cuando el HTML y el CSS que hayas definido para tu página es enviado a un navegador Web, es traducido desde texto a un modelo de objeto. Esto es cierto, así sea el código simple o complejo, contenido todo en un archivo o en archivos separados. El navegador trabajara entonces directamente con el modelo de objeto, más que con los archivos de texto que le entregaste. El modelo que el navegador usa se llama El Modelo de Objeto de Documento. Este conecta los objetos representando los elementos, atributos y texto en tus documentos. Todos los estilos, valores y más que nada los espacios en tu HTML y CSS son incorporados en el modelo de objetos. El modelo especifico para una página Web dada se llama "Arbol DOM" de la página.
Entender que es un árbol DOM, y mas conocer como representa tu HTML y CSS, es solo el primer paso para tomal el control de tus páginas Web. Después tenés que aprender como trabajar con el árbol DOM para una página Web particular. Por ejemplo, si agregas un elemento al árbol DOM, ese elemento inmediatamente aparece en el navegador Web del usuario--sin que se recargue la página. Eliminas algo de texto del árbol DOM y ese texto desaparece de la pantalla del usuario. Podes cambiar e interactuar con la interface del usuario a traves del DOM, que te da un tremendo poder y flexibilidad de programación. Una vez que aprendas como trabajar con un árbol DOM habrás hecho un gran salto hacia dominar ricos, interactivos y dinámicas páginas Web.
Observar que la siguiente discusión está basada en "Explotar el DOM para una respuesta Web" del mes pasado; si no has leido ese artículo, puede ser que prefieras hacerlo antes de seguir con esto.

Importancia de la pronunciación del acrónimo.
De todas formas, el modelo de objeto de documento, se habría podido llamar Modelo de Nodos de documentos. Por supuesto , la mayoría de la gente no sabe que significa el término nodo, y DNM no es tan fácil de pronunciar como DOM, por eso es fácil entender porque el W3C siguió con DOM.

Cruce de navegadores, cruce de lenguajes.
El modelo de objeto de doumento es un estandar de la W3C (ver Recursos por links a la W3C). Por esto, todos los navegadores Web modernos soportan DOM, al menos en algun grado. Si bien hay algunas variaciones entre navegadores, si usas la funcionalidad basica de DOM --y pones atencion a algunos casos especiales y excepciones-- tu código DOM va a trabajar en cualquier navegador de la misma manera. El código que escribas para modificar una pagina Web en Opera va a trabajar en el Safari de Apple, en Firefox, en Microsoft Internet Explorer y Mozilla.
El DOM es también una especificación de cruce de lenguajes; en otras palabras, podes usarlo desde la mayoria de los lenguajes de programación más populares. La W3C define varios vinculos de lenguaje para el DOM. Por ejemplo, podes encontrar vínculos de lenguaje para DOM bien definido para C, Java y JavaScript. Por esto podes usar DOM con cualquiera de esos lenguajes. Los vinculos de lenguaje estan disponibles también para muchos otros lenguajes, aunque muchos de estos no estan definidos por la W3C, sino en su lugar por terceros.
En esta serie me voy a enfocar en los vínculos de JavaScript en el DOM. Esto tiene sentido por que la mayoría de los desarrollos de aplicaciones asincronicas estan basados en escribir código JavaScript para ejecutar en un navegador Web. Con JavaScript y DOM, podes modificar la interfase del usuario al vuelo, responder a los eventos de los usuarios y a las entradas, y más --todo usando JavaScript bastante estandarizado.
Todo lo dicho, te animo a que revises los vinculos de lenguaje para DOM en otros lenguajes. Por ejemplo, podes usar los vinculos del lenguaje Java no solo para trabajar con HTML, sino tambien con XML, como voy a analizar en un artículo más tarde. Entonces las lecciones que aprenderas acá se aplican mucho mas que en HTML, en muchos mas ambientes que solo el lado cliente JavaScript.
El nodo conceptual
Un nodo es mas que un tipo de objeto básico en el DOM. De hecho, como verás en este artículo, casi todo otro objeto definido por DOM extiende el objeto del nodo. Pero, antes de que llegues muy lejos en la semantica, necesitas entender el concepto que se representa con un nodo; luegopara aprender las propiedades reales y metodos de un nodo es un pabada.
En un árbol DOM, casi todo lo que vas a encontrar es un nodo. Todo elemento es en su nivel más básico un nodo en el árbol DOM. Todo atributo es un nodo. Todo fragmento de texto es un nodo. Hasta los comentarios, caracxteres especiales (como ©, que representa eun simbolo de copyright), la declaracion DOCTYPE (si tenes una en tu HTML o XHTML) son todos nodos. Entonces antes de meterme en lo especifico de cada uno de esos typos individuales, realmente necesitas concer que es un nodod.
Un nodo es...
En términos simples, un nodo es solo una unica cosa en el arbol DOM. Lo vago de "cosa" es intencional, porque asíe s de especifico como puede ser. Por ejemplo, probablemente no es obvio que un elemento en tu HTML, como img, y un fragmento de texto en HTML, como "Bajar para más detalles" tengan mucho en comun. Pero eso es porque probablemente estes pensando en la función de esos tipos individuales, y enfocando en cuan diferentes son.
Considera, en su lugar, que cada elemento y fragmento de texto en un árbol DOM tiene un padre; ese padre es tambien el hijo de otro elemento (como cuando una imagen es anidada dentro de un elemento p) o es el primer elemento en el árbol DOM (que es un caso espaciel único para cada documento, y es donde se usa el elemento HTML). Considerar tambien que que ambos, elementos y texto, tienen un tipo. El tipo de un elemento es obviamente un elemento; el tipo de texto es texto. Cada nodo tiene tambien una estructura bastante bien definida para eso: Tiene un nodo (o nodos) debaajo de él, como elementos hijos? Tiene nodos hermanos (nodos "al lado de" el elemento o texto)? A que documento pertenece cada nodo?
Obviamente, mucho de esto suena bastante abstracto. De hecho, puede parecer tonto decir que el tipo de un elemento es... bueno... un elemento. Sin embargo, necesitas pensar un poco abstractamente para darte cuenta el valor de tener el nodo como un tipo de objeto común.
El tipo de nodo comun
La tarea simple que vas a realizar mas que ninguna otra en tu código DOM es navegar dentro de el árbol DOM de una página. Por ejemplo, podrías localizar un formulario por su atributo, y luego empezar a trabajar con el elemento y texto anidado en ese formulario. Van a haber intrucciones textuales, etiquetas para campos de entrada, elementos de ingreso reales, y pasiblemente otro tipo de elementos HTML como elementos img y links (un elemento). Si elementos y texto son tipos completamente diferentes, entonces tenés que escribir piesas de código completamente diferentes para mover desde un tipo a otro.
Las cosas son diferentes si usas un tipo de nodo comun. En ese caso podes simplemente moverte de nodo a nodo y preocuparte sobre el tipo solo cuando querés hacer algo específico con un elemento o texto. Mientras solo te muevas en el árbol DOM, vas a usar las mismas operaciones para moverte al padre del elemento --o a sus hijos-- como lo harias con cualquier tipo de nodo. Solo vas a tener que trabajar específicamente con un tipo de nodo, como un elemento o texto, cuando necesitás algo específico de determinado tipo de nodo, como un atributo de un elemento. Pensar en cada elemento del árbol DOM simplemente como un nodo te permite operar mucho mas sencillamente. Con eso en mente, voy a ver exactamente que tiene que ofrecer la construcción Nodo de DOM, empezando con propiedades y métodos.

Traducción de artículo de Ajax XXII

2006-07-04T13:08:00.000-03:00

Introducir el DOM
Hasta ahora has escuchado que los navegadores transforman una página Web a una representación de objeto y tal vez también hayas adivinado que la representación de Objeto es un árbol DOM. DOM sustituye a Modelo de Objeto de Documento y es una especificación disponible para la World Wide Web Consortium (W3C) ( podes ver varios links relacionados con DOM en los recursos)
Más importante todavía, el DOM define los tipos de objeto y propiedades que permiten al navegador representar el markup (El próximo artículo de esta serie se focaliza en las especificaciones de uso de DOM para tu JavaScript y código Ajax).
El Objeto documento
Primero y principal, vas a necesitar acceder al modelo de objeto en si mismo. Esto es extraordinariamente fácil; para usar la variable incorporada document en cualquier parte del código JavaScript funcionando en tu página Web, podes escribir código como este:

var domTree = document;

Por supuesto, este código es bastante inútil de por si, pero demuestra que todo navegador Web pone a disposición el objeto document para el código JavaScript y que el objeto representa el árbol completo del markup (figura 1).
Todo es un nodo
Claramente, el objeto document es importante, pero solo es el comienzo. Antes de que puedas ir más lejos, necesitas aprender otro término: nodo. Ya sabés que cada parte del markup es representada por un objeto, pero es más que cualquier objeto -- es un tipo de objeto especifico, un nodo DOM. Los tipos más específicos --como texto, elemento y atributos-- son extensiones del este tipo de nodo básico. Así que tenés nodos de texto, nodos de elementos y nodos de atributos.
Si has programado mucho en JavaScript, debería ocurrirte que ya has usado código DOM. Si seguiste esta serie de Ajax hasta este momento, definitivamente has usado código DOM en algún momento ahora. Por ejemplo, la línea var number = document.getElementById("phone").value; usa DOM para encontrar un elemento especifico y devolver el valor de ese elemento (en este caso, un campo de formulario). Aunque no te hayas dado cuenta, usaste DOM cada vez que escribiste document en tu código JavaScript.
Para refinar los términos que ya has aprendido, un árbol DOM en un árbol de objetos, pero más específicamente en un árbol de objetos nodo. En aplicaciones Ajax --o cualquier otro JavaScript-- podés trabajar con esos nodos para crear efectos tales como remover un elemento y su contenido, resaltar una parte del texto o agregar un nuevo elemento de imagen. Como todo esto ocurre en el lado cliente (código que se ejecuta en tu navegador Web), estos efectos tiene lugar inmediatamente sin comunicación con el servidor. El resultado final es una aplicación que se siente que responde bien por que las cosas en la página Web cambian sin largas pausas mientras que una petición va al servidor en una respuesta es interpretada.
En la mayoría de los lenguajes de programación, necesitas aprender el nombre de objeto real para cada tipo de nodo, aprender las propiedades disponibles y comprender sobre tipos y elencos; pero ninguno de estos es necesario en JavaScript. Podes, simplemente crear una variable y asignarla en el objeto que quieras (tal como has visto):

var domTree = document;
var phoneNumberElement = document.getElementById("phone");
var phoneNumber=phoneNumberElement.Value;

No hay tipos y JavaScript se encarga de crear las variables y asignarles el tipo correcto como sea necesario. Como resultado, se vuelve bastante trivial usar DOM desde JavaScript (en un artículo próximo nos focalizaremos en DOM relacionado con XML y cosas que son un poco mas difíciles).
En Conclusión
En este punto, te voy a dejar con muchas preguntas sin respuestas. Obviamente, esto no ha sido una cobertura exaustiva del DOM; de hecho este articulo es un poco más que una introducción al DOM. Hay mucho mas DOM del que te he mostrado hoy!
El próximo artículo de esta serie se expande en esas ideas y profundiza mas en como podés usar DOM en tu JavaScript para actualizar páginas Web, hacer cambios al vuelo en tu HTML y crear una experiencia mas interactiva para tu usuario. Voy a volver al DOM una vez mas en los últimos artículos que focalizarán en usar XML en tus peticiones AJAX. Así que familiarizate con el DOM; es la parte principal de las aplicaciones Ajax.
Seria bastante simple lanzar más del DOM en este punto, detallar como moverse dentro de un árbol DOM, obtener los valores de los elementos y el texto, iterar en las listas de nodos, y mas, pero eso probablemente te dejaría con la impresión de que DOM es sobre código --no lo es.
Antes del próximo artículo, trata de pensar sobre estructuras de árbol y trabaja en algunos de tus propios HTML para ver como un navegador Web cambia es HTML a una vista de árbol del markup. También, piensa en la organización del árbol DOM y trabaja en los casos especiales analizados en este artículo: atributos, texto que tiene elementos mezclados dentro de él, elementos que no tiene contenido de texto (como el elemento img).
Si obtenés una comprensión firme de esos conceptos y luego aprendes la sintaxis de JavaScript y de DOM (en el próximo artículo), va a hacer el trabajo de hacer que responda bien, mucho más fácil.
Y no te olvides, acá están las respuestas de los listings 2 y 3 que también están incluidas en el código de muestra.

Figura 2. Respuesta del Listing 2

Figura 3. Respuesta del Listing 3

Traducción de Artículo de Ajax XXI

2006-06-22T18:07:00.000-03:00

El valor de los objetos
Ahora que tenés alguna terminología básica en tu haber, es hora de enfocar mas en esos pequeños rectángulos con nombres de elementos y texto adentro. (figura 1). Cada rectángulo es un objeto; ahí es donde el navegador resuelve algunos de esos problemas con el texto. Usando objetos para representar cada parte del documento HTML, se vuelve muy fácil cambiar la organización, aplicar estilos, permitir a JavaScript acceder al documento y mucho mas.
Tipos de Objetos y Propiedades
Cada tipo posible de markup tiene su propio tipo de objeto. Por ejemplo, los elementos en u HTML son representados por un objeto tipo element. El texto en tu documento es representado por un tipo Text, los atributos son representados por tipos Attribute y así con todos.
Entonces el navegador Web no solo tiene la posibilidad de usar un modelo de objetos para representar tu documento --dejando de lado el hecho de que tiene que tratar con texto estático--sino que también puede decir inmediatamente que es algo por su tipo de objeto. El documento HTML es analizado y convertido en un grupo de objetos como el que viste en la figura 1 y luego cosas como paréntesis angulares y secuencia de escape no son mas un problema. Esto hace que el trabajo de navegador, al menos después de que analiza el HTML de la entrada, mucho más simple. La operación para descubrir si algo es un elemento o un atributo y luego determinar que hacer con ese tipo de objeto es simple.
Usando objetos, el navegador Web puede entonces cambiar las propiedades de esos objetos. Por ejemplo, cada elemento tiene un padre y una lista de hijos. Por eso agregar un nuevo elemento o texto hijo es simplemente un asunto de agregar un nuevo hijo a una lista de hijos de un elemento. Esos objetos tiene también una propiedad style, por esto se vuelve fácil cambiar el estilo de un elemento o parte de texto al vuelo. Por ejemplo, podrías cambiar la altura de un div usando JavaScript como este:

someDiv.style.height = "300px";

En otras palabras, los navegadores Web pueden cambiar fácilmente la apariencia y estructura del árbol usando propiedades de objetos como esta. Comparando esto con la calse de cosas complicadas que el navegador tiene que hacer si representa la página como texto internamente; cada cambio de propiedades o estructuras que el navegador reescriba el archivo estático, lo re-analice y lo vuelva a mostrar en la pantalla. Todo esto se vuelve posiblo con objetos.
En este punto, tomate el tiempo de abrir algunos de tus documentos HTML y esquematizarlos como árbol. Así como este parece ser un pedido bastante inusual --especialmente de un artículo que contiene tan poco código -- vas a necesitar familiarizarte con la estructura de esos arboles si querés poder manipularlos.
En el proceso, probablemente te encuentres con otras rarezas. Por ejemplo, consideremos las siguientes situaciones:

¿Qué pasa con los atributos?
¿Qué pasa con el texto que es interrumpido por elementos, como em y b?
¿Y qué pasa con el HTML que no esté estructura do correctamente (como cuando falta la etiqueta de cierre p)

Una vez familiarizado con estos temas, vas a entender algunas de las próximas mucho mejor.
Estricto es algo bueno
Si intentaste el ejercicio que acábo de mencionarte, probablemente encontraste algunos de los problemas potenciales de una vista de árbol en tu markup (si no hiciste el ejercicio, solo toma mi palabra). De hecho, vas a encontrar muchos de ellos en el listing 1 y en la figura 1, empezando por la manera en que el elemento p se interrumpe. Si le preguntás al típico desarrollador Web cual es el contenido del elemento p, la respuesta más común sería, "Bienvenido a una página realmente aburrida" y si comparás esto con la figura 1, vas a ver que esa respuesta --aunque lógica-- no es totalmente correcta.
Resulta que el elemento p tiene tres objetos hijo diferentes y ninguno contiene todo el texto "Bienvenidos a una página realmente aburrida". Vas a encontrar partes de ese texto, como "Bienvenido a una Pagina Web" y "aburrida", pero todo completo. Para entender esto, recuerda que todo en tu markup tiene que ser convertido en un objeto de algún tipo.
Es más, el orden importa! ¿Podes imaginarte como los usuarios responderían a un navegador Web si este muestra el markup correcto, pero en un orden diferente que el que vos le diste en tu HTML? ¿Los párrafos se intercalan entre títulos y cabeceras, aún cuando así no es como vos organizaste tu propio documento? Obviamente, el navegador debe preservar el orden de los elementos y el texto.
En este caso, el elemento p tiene tres partes distintas:

El texto que va antes del elemento em
El elemento em mismo
El texto que va después del elemento em

Si mezclas este orden, podrías aplicar el énfasis en una porción errónea del texto. Para mantener todo esto en orden, el elemento p tiene tres objetos hijos en el orden que esas cosas aparecieron en el HTML del Listing 1. Además, el texto enfatizado "realmente" no es un hijo del elemento p, es un hijo del em que es un hijo de p.
Es muy importante para vos entender este concepto. Aun cuando el texto "realmente" se va a ver probablemente junto con el resto del texto del elemento p, igual es un hijo directo del elemento em. Puede tener formato diferente del resto del p y puede ser movido independientemente del resto del texto.
Para ayudar a consolidar esto en tu mente, trata de diagramar el HTML de los listings 2 y 3, asegurándote de mantener el texto con su padre correcto (a pesar de como el texto se termine viendo en la pantalla).

Listing 2. markup con anidación de elementos levemente difícil.

<html>
<head>
<title> Este es un poquito difícil</title>

</head>
<body>
<h1>Poné<u>mucha</u> atención, OK?

</h1>
<div>
<p>
Este p no es realmente <em>necesario</em>, pero hace la <span id="bold-text">estructura <i> y </i>la organización</span> de la página fácil de mantener
</p>
</div>

</body>
</html>

Listing 3. Anidación de elementos un poco más difícil.

<html><head><title> Este es un poquito difícil</title> </head>
<body>
<div id="main-body">
<div id="contents">
<table>
<tr> <th>Pasos </th> <th>Proceso </th> </th>
<tr> <td>1 </td><td>Descubre el <em>elemento raiz</em>. </td> </tr>
<tr> <td>2 </td><td>Trabajar con la <span id="code">cabecera</span> primero, es normalmente fácil. </td> </tr>
<tr> <td>3 </td><td>Trabajar en el <span id="code">cuerpo</span>. Solo <em>tomate tu tiempo </em>.</td> </tr>
</table>
</div>
<div id="closing">
Este link <em>no</em> está activado, pero si lo estuviera, las respuestas a esto <a href=" answers.html"><img="exercise.gif" /></a>estarían ahí. Pero <em>hacé el ejercicio igual </em>
</div>
</div>
</body>
</html>

Vas a encontrar las respuestas de estos ejercicios en los archivos GIF tricky-solution.gif en figura 2 y trickier-solution.gif en figura 3 al final de este artículo. No las mires hasta que hayas tenido el tiempo de resolverlos vos mismo. Te ayudara a entender como aplicar las reglas estrictamente para organizar el árbol y realmente ayudarte en tu búsqueda de dominar HTML y su estructura de árbol.
¿Qué pasa con los atributos?
¿Te encontraste con algún problema cuando trataste de descubrir que hacer con los atributos? Como mencioné, los atributos tienen su propio tipo de objeto, pero un atributo nos es realmente un hijo del elemento en donde aparece --elementos anidados y texto no están al mismo nivel de un atributo y vas a notar que las respuestas de los ejercicios en los listings 2 y 3 no tiene atributos mostrados.
Los atributos de hecho son almacenados en el modelo de objeto que usan los navegadores, pero son un caso especial. Cada elemento tiene una lista de atributos disponibles, separado de la lista de objetos hijos. Entonces un elemento div podría tener una lista que contenga un atributo llamado "id" y otro llamado "class".
Ten en mente que los atributos de un elemento deben tener nombres únicos; en otras palabras, un elemento no puede tener dos atributos "id" u dos "class". Esto hace que la lista sea muy fácil de mantener y acceder. Como vas a ver en el próximo artículo, podes simplemente llamar a un método como getAttribute("id") para obtener el valor de un atributo por su nombre. Podes también agregar atributos y establecer ( o poner a cero) el valor de un atributo existente con un llamado a método similar.
También vale la pena precisar que el hecho de que los nombres de los atributos sean únicos hace es ta lista diferente de la lista de objetos hijo. Un elemento p puede tener múltiples elementos em dentro de el. entonces la lista de objetos hijo puede contener ítem duplicados. Si bien la lista de hijos y la lista de atributos operan de manera similar, una puede contener duplicados (los hijos de un objeto)y la otra no (los atributos de un elemento objeto). Finalmente, solo los elementos pueden tener atributos, entonces los objetos de texto no tienen listas asociadas a ellos para almacenar atributos.
HTML descuidado
Antes de continuar, un tema nuevo vale la pena un tiempo cuando viene de cómo un navegador convierte el markup en una representación de árbol -- cómo un navegador se encarga del markup que no esta bien armado. Bien armado es en realidad un termino muy usado en XML y significa dos cosas básicas:

Toda etiqueta de apertura tiene una etiqueta de cierre coincidente. Entonces todo <p> se relaciona en el documento con un </p>, todo <div> con un </div>, y así sucesivamente.
La etiqueta de apertura más interior hace juego con la etiqueta de cierre mas interior, luego la siguiente etiqueta de apertura más interior con la siguiente etiqueta de cierre mas interior y así sucesivamente. Por eso <b><i>negritas e itálicas </b></i> sería ilegal porque la etiqueta de apertura <i> esta incorrectamente relacionada con la etiqueta de cierra más interior <b>. Para armar bien esto, necesitarías cambiar el orden de las etiquetas de apertura u el orden de las etiquetas de cierre. (si se cambian ambas, mantendrías el problema)

Estudia estas dos reglas atentamente. Ambas son reglas que no solo aumentan la sencilla organización de un documento, sino que también eliminan la ambigüedad. ¿Debería aplicarse negritas primero y luego itálicas? ¿o al revés? Si parece que este orden y ambigüedad no es un gran problema, recuerda que CSS permite a las reglas que sobrescriban otras reglas para, por ejemplo, la fuente del texto entre elementos b sea distinta de la fuente entre elementos i, el orden en el cual el formato sea aplicado se vuelve muy importante. Por lo tanto, el buen formato de una página HTML entra en juego.
En los casos donde un navegador recibe un documento que no esté bien armado, hace simplemente lo mejor que puede. La estructura de árbol resultante es en el mejor de los casos, una aproximación de lo que el autor original de la pagina previó o peor algo completamente diferente. Si cargaste tu pagina en un navegador y viste algo completamente inesperado, puede ser que hayas visto el resultado de un navegador tratando de adivinar que debería ser tu estructura y haciendo el trabajo mal. Por supuesto, la solución a esto es bastante simple: ¡asegurate de que tus documentos estén bien armados! Si no tenés claro como escribir HTML estandarizado como este, consultá los recursos por ayuda.

Traducción de Artículo de Ajax XX

2006-06-13T16:12:00.000-03:00

Que hace el markup
Una vez que te des cuenta de que tu markup es realmente sobre organización, podes verlo diferente. Mas que pensar que un H1 hace que el texto se vea mas grande, en color Negro, estilo Negritas, pensá el H1 como un heading. Como ve el usuario eso -- y si el usuario usa tu CSS, la suya, o alguna combinación de las dos--es una consideración secundaria. En su lugar, date cuenta de que el markup es realmente sobre proveer este nivel de organización; un p indica que ese texto está en un párrafo, img denota una imagen, div divide un página en secciones y así sucesivamente.
Deberías tener claro también que estilo y comportamiento (gestionadores de eventos y JavaScript) son aplicados a esta organización, después de todo. El markup tiene que estar en su lugar para operar sobre el o aplicarle estilo. Entonces, como probablemente tengas CSS en un archivo externo a tu HTML, la organización de tu markup está separada de su estilo, formato y comportamiento. Así como ciertamente podés cambiar el estilo de un elemento o pieza de texto desde JavaScript, es más interesante cambiar la organización que tu markup presenta.
Mientras que mantengas en la mente que tu markup solo provee organización, o marco, a tu página, estás adelante en el juego. Y un poco mas todavía, vas a ver como el navegador toma esta organización textual y la transforma en algo mucho más interesante --un grupo de objetos, cada uno de los cuales pueden ser cambiados, agregados o borrados.
Las ventajas del markup de texto
Antes de referirme al navegador Web, vale la pena considerar porqué el texto plano es absolutamente la mejor opción para almacenar tu HTML (para mas de esto, ver algunos pensamientos adicionales sobre markup ). Sin entrar en pro y contra, simplemente resalto que tu HTML es enviado a través de la red a una navegador Web toda vez que la página es vista (poniendo el cache y demás a un lado por motivos de simplicidad). Simplemente no hay abordaje más eficiente que pasar por texto. Objetos binarios, representaciones gráficas de la página, y partes reorganizadas del markup... todas ellas son mas difícil de enviar a través de la red que archivos de texto plano.
Adicionar a eso el valor que un navegador agregar a la ecuación. Los navegadores de hoy permiten a los usuarios cambiar el tamaño del texto, escalar imágenes, descargar el CSS o JavaScript de una página (en la mayoría de los casos) y mucho más --todo esto imposibilita todo tipo de representación gráfica de la página al navegador. En cambio, el navegador necesita el HTML crudo para poder aplicar cualquier proceso a la página en el navegador más que confiar en al servidor que se encargue de esa tarea. En la misma linea, separar CSS del JavaScript y separar estos del markup HTML requiere un formato que se fácil de, bueno, separar. Archivos de texto otra vez son una manera genial de hacer esto.
Por ultimo, pero no menos importante, recuerda que la promesa de los nuevos estándares como HTML 4.01 y XHTML 1.0 y 1.1 separan contenido (la información en tu página) de presentación y estilo (normalmente aplicado con CSS). Para los programadores separar si HTML de sus CSS, luego forzar a un navegador a devolver alguna representación de una página que una todo eso junto, frustra muchas de las ventajas de esos estándares. Mantener esas partes dispares separadas hasta el navegador le permite mayor flexibilidad al obtener el HTML del servidor.

Algunos pensamientos adicionales sobre markup
Editar texto plano:¿bien o mal?
Los archivos de texto plano son ideales para guardar markup, pero eso no es así para editar el markup. Es perfectamente aceptable el uso de un IDE como Macromedia DreamWeaver --o el un tanto mas intrusivo Microsoft Front Page-- para trabajar en el markup de la página. Esos ambientes a menudo ofrecen atajos y ayuda al crear páginas Web, especialmente cuando estas usando CSS y JavaScript, cada uno de un archivo externo a un markup de pagina real. Muchos todavía prefieren el viejo y querido Notepad o Vi (lo confieso yo soy uno de ellos) y es una gran opción también. En todo caso, el resultado final es un archivo de texto lleno de markup.
Texto sobre la red: algo bueno.
Como ya se mencionó, el texto es un gran medio para un documento --como HTML o CSS-- que es transferido por la red cientos y miles de veces. Cuando digo que el navegador tiene un tiempo difícil representando el texto, significa específicamente transformar el texto en un página gráfica que los usuarios ven. Esto no tiene relación con como el navegador realmente recupera una página del servidor Web; en ese caso, el texto es todavía más la mejor opción.

Una mirada mas profunda a los navegadores Web
Para algunos de ustedes, todo lo que han leído hasta ahora puede ser una revisión divertida de tu rol en el proceso del desarrollo Web. Pero en lo que concierne a que hace el navegador Web, muchos de los diseñadores y desarrolladores Web mas listos a menudo no se dan cuenta de que pasa realmente "abajo del capot". Me focalizaré en eso en esta sección. Y no te preocupes, el código vendrá pronto, pero aguanta tu impaciencia de codificar por que entender exactamente que hace un navegador Web es esencial para que trabajes en tu código correctamente
Las desventajas del markup de texto
Justamente como texto el markup tiene ventajas fabulosas para un diseñador o un creador de páginas, también tiene desventajas un tanto significativas para el navegador. Específicamente, los navegadores tienen un tiempo muy difícil en cuanto a representar markup de texto visualmente para el usuario (para mas de esto, ver algunos pensamientos adicionales sobre markup)Considerar estas tareas frecuentes del navegador:

Aplicar estilos CSS --frecuentemente de múltiples hojas de estilo en archivos externos-- para un markup basado en el tipo de elementos, sus clases, sus ids y sus posiciones en el documento HTML.
Aplicar los estilos y formatos basados en código JavaScript --también frecuentemente en archivos externos-- a partes diferentes del documento HTML.
Cambiar el valor de los campos de formulario basado en el código JavaScript
Dar soporte a efectos visuales como rollover e intercambio de imágenes en código JavaScript.

La complejidad no está en codificar esas tareas; es bastante fácil hacer cada una de esas cosas. La complejidad viene desde el navegador realmente, llevando a cabo la acción solicitada. Si el markup es almacenada como texto y, por ejemplo, querés centrar el texto (text-align: center) de un elemento p en la clase center-text,¿como lográs esto?

¿Agregás estilo en la linea del texto?
¿Aplicás el estilo al texto HTML en el navegador y solo continuas con cual contenido centrar o no centrar?
¿Aplicás HTML sin estilo y luego aplicas el formato?

Estas tan difíciles preguntas son porqué pocas personas codifican navegadores estos días. (Esos quienes deberían recibir un caluroso agradecimiento)
Claramente, texto plano no es una gran manera de guardar HTML para el navegador aun cuando el texto fuera una buena solución para obtener el markup de una página en primer lugar. Sumale a esto la habilidad de JavaScript de cambiar la estructura de una página y las cosas se vuelven realmente difíciles. ¿Debería el navegador reescribir la estructura modificada al disco? ¿Como puede actualizar con cual es la etapa actual del documento?
Claramente, texto no es la respuesta. Es difícil de modificar, torpe para aplicar estilos y comportamiento y lleva en última instancia poca semejanza a la naturaleza dinámica de Web pages de hoy.
Mudanza a una vista de árbol
La respuesta a este problema --al menos, la respuesta elegida por los navegadores Web de hoy en día-- es usar una estructura de árbol para representar HTML. Veamos el listing 1 , una página HTML bastante simple y aburrida representada como texto markup.

Listing 1 Pagina HTML simple en markup de texto

<html>
<head> <title>Arboles, árboles por todas partes</title>
</head> <body>
<h1> Arboles, árboles por todas partes</h1>
<p> Bienvenido a una página <em>realmente</em> aburrida</p>
<div>
Vuelve pronto.
<img scr="come-again.gif" />
</div>
</body>
</html>

El navegador toma esto y lo convierte en una estructura como árbol, como en la figura 1
Figura 1. La vista de árbol del listing 1

Hice algunas simplificaciones menores para mantener este artículo en tema. Los expertos en DOM o XML se van a dar cuenta que ese espacio en blanco puede tener un efecto en como el texto es representado en un documento y una ruptura en la estructura de árbol del navegador Web. Meterse en esto suma poco y confunde el tema, entonces si sabés sobre el efecto del espacio en blanco, genial, si no, continua leyendo y no te preocupes por el. Cuando se convierta en un tema, vas a encontrar todo lo que necesites en ese momento. el árbol empieza con el elemento contenedor mas exterior que es el elemento HTML. Este se llama el elemento raíz(root) manteniendo la metáfora del árbol. Aunque esté en la parte inferior del árbol, siempre empieza acá cuando observes y analices arboles. Si te ayuda, podes dar vuelta el esquema, aunque se pierde un poco la metáfora del árbol.
De la raíz surgen lineas que muestran las relaciones entre las diferentes partes del markup. los elementos head y el body son hijos del elemento raíz html; title es un hijo de head y luego el texto "Arboles, arboles, en todas partes" es un hijo de title. El árbol entero se organiza así, hasta el navegador obtiene una estructura similar a lo que ves en la figura 1.
Algunos términos adicionales
Para continuar con la metáfora del árbol, head y body se dice que son ramas del html. Son ramas por que ellas por su lado tienen sus propios hijos. SI vas a las extremidades del árbol, te vas a encontrar mayormente con texto como "Arboles, árboles, por todos lados" y "realmente". A estos normalmente nos referimos como Hojas por que no tienen hijos. No necesitas memorizar esos términos y es frecuentemente mas fácil solo visualizar la estructura de árbol cuando trates descubrir que significa un término particular.

Traducción de Artículo de Ajax XIX

2006-06-09T10:29:00.000-03:00

Dominar Ajax Parte 4: Explotar DOM para la respuesta Web
Convertir HTML en un Modelo de Objetos para hacer las paginas Web Dinámicas e interactivas

Nivel: Introductorio

Brett McLaughlin (brett@oreilly.com), Autor y Editor, O´Reilly y Asociados.
14 Mar 2006

La gran división entre programadores (que trabajan con aplacaiones Back-end) y Programadores Web (que gastan su tiempo escribiendo HTML, CSS y JavaScript)es de muchos años. Sin embargo, el Modelo de Objetos de Documento (DOM) rompe las distancias, y hace posible trabajar con ambos XML en el Back-end y HTML en el front-end y como un herramienta efectiva. En este artículo, Brett McLaughlin introduce el Modelo de Objetos de Documento, explica su uso en las páginas Web y empieza a explorar su uso desde JavaScript.

Como muchos programadores Web, probablemente hayas trabajado con HTML. HTML es como los programadores empiezan a trabajar en una página Web; HTML es a menudo la última cosa que hacen al terminar una aplicación o sitio, y un poco de colocación, color o estilo. Y tan común como es el uso de HTML, es la idea equivocada de que es exactamente lo que le pasa a ese HTML una vez que va al navegador para generar la pantalla. Antes, profundizo en que podrías pensar que sucede --y por que es probablemente erróneo--quiero que tengas claro el proceso involucrado en el diseño y el servicio de páginas web:

Alguien (normalmente vos!) crea HTML en un editor de texto o IDE
Luego subes el HTML a un servidor Web, como Apache HTTPD, lo haces publico en Internet o en una intranet.
Un usuario solicita tu página Web con un navegador como FireFox o Safari
El navegador del usuario hace una petición del HTML a tu servidor Web
El navegador muestra la página que recibió del servidor gráficamente y textualmente; el usuario mira y activa la página Web.

Mientras que esto se siente muy básico, las cosas se volverán interesante rápidamente. De hecho, la tremenda cantidad de "cosas" que pasan entre los pasos 4 y 5 es lo que enfoca este artículo. El termino "cosas" realmente se aplica también, ya que la mayoría de los programadores nunca consideran lo que pasa exactamente a su especificación de formato(markup) cuando un usuario pide que se lo muestre:

¿El navegador solo lee el texto en el HTML y lo muestra?
¿Que pasa con CSS, espacialmente si el CSS esta en un archivo externo?
¿Y sobre JavaScript -- otra vez a menudo en un archivo externo?
¿Como el navegador gestiona esos ítem y como relaciona los gestionadores de eventos, funciones y estilos para esta especificación de formato (markup) textual?

Resulta que la respuesta a todas esas preguntas es el Modelo de Objetos de Documento. Entonces, sin más complicaciones, vamos a profundizar en DOM.
Programadores Web y especificación de formato (markup)
Para la mayoría de los programadores, su trabajo termina donde el navegador Web empieza. En otras palabras, una vez que colocaste un archivo HTML en un directorio en tu servidor Web, generalmente la archivas como lista y (esperanzadamente) nunca pensás realmente en ella de nuevo. Esa es una gran meta cuando viene de la escritura limpia, páginas bien-organizadas, también; no hay nada de malo con querer que tu especificación de formato muestre lo que debe, en todos los navegadores, con varias versiones del CSS y del Javascript.
El problema es que esta manera limita la comprensión del programador de que es lo que realmente pasa en el navegador. Mas importante, limita tu habilidad de actualizar, cambiar y reestructurar una página Web dinámicamente usando JavaScript del lado cliente. Sacate de encima esa limitación, y permite una todavía más grande interacción y creatividad en tu páginas Web.
Lo que hacen los programadores
Como típico programador Web, probablemente dispares tu editor de texto y IDE y empezás a ingresar HTML, CSS, o más, JavaScript. Es fácil pensar en esas etiquetas y selectores y atributos solamente como pequeñas tareas para hacer que un sitio de vea bien. Pero necesitas flexibilizar tu mente más allá de ese punto -- en su lugar, darte cuenta de que estas organizando tu contenido. No te preocupes; te prometo esto no se va a transformar en una lectura sobre la belleza del markup lo que tenés que darte cuenta es el verdadero potencial de tu página Web, y todo lo metafísico más. Lo que necesitas entender es exactamente cual es tu rol en el desarrollo Web.
Cuando viene como se ve una página, a lo mejor solamente podes hacer sugerencias. Cuando proporcionas una hoja de estilos CSS, un usuario puede invalidar tus elecciones de estilo. Cuando proporcionas un tamaño de fuente, un navegador de un usuario puede alterar esas medidas para los de visión disminuida o escalarlo en monitores masivos (con resoluciones igualmente masivas). También los colores y los tipos de fuentes que elegiste están sujetas al monitor de los usuarios y a las fuentes que los usuarios instalen en sus sistemas. Si bien es genial que hagas lo mejor que puedas en el estilo de una página, ese no es el más grande impacto que tienes en una página Web.
Lo que vos controlás absolutamente es la estructura de tu página Web. Tu markup no se puede cambiar, es inalterable y los usuarios no puede hacer un lio con el; sus navegadores solo pueden recuperarlo del servidor y mostrarlo (no obstante, con un estilo más conforme al gusto del usuario que al tuyo). Pero la organización de esta página --este esta palabra dentro de ese párrafo en en el otro div-- es únicamente tuya. Cuando realmente hay que cambiar tu página (que es lo que las aplicaciones Ajax más focalisan), es la estructura de tu página la que trabajas. Si bien es lindo cambiar el color de una parte del texto, es mucho mejor agregar texto o una sección entera a una página existente. No importa el estilo que el usuario le de a esa sección vos trabajás con la organización de la página misma.

Traducción de Artículo de Ajax XVIII

2006-06-05T15:56:00.000-03:00

Tipos de peticiones adicionales
Si realmente quieres tener el control del objeto XMLHttpRequest, considera este última parada -- agregar peticiones HEAD a tu repertorio. En los dos artículos previos, te mostré como hacer peticiones GET, en un próximo artículo, vas a aprender todo sobre mandar información al servidor usando las peticiones POST. Con el espíritu de realzar la gestión de errores y la reunión de información, debes aprender como hacer peticiones HEAD.
Hacer la Petición
Realmente hacer una petición HEAD es absolutamente trivial. Simplemente llama al método open() con HEAD en vez de GET o POST como primer parámetro, como de muestra en el listing 9.

Listing 9. Hacer una petición HEAD con Ajax

function getSalesData(){
createRequest();
var url = "/boards/servlet/UpdateBoardSales";
request.open("HEAD", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}

Cuando haces una petición HEAD como esta, el servidor no devuelve una respuesta real como lo haría para una petición GET o POST. En su lugar, el servidor solo tiene que devolver las cabeceras de la fuente que incluye la ultima hora que el contenido de la respuesta fue modificado, si la fuente de la petición existe o no, y algunas otras partes interesantes de información. Podés usar varias de esas para descubrir sobre un recurso antes que el servidor haya procesado y devuelto ese recurso.
La cosa mas fácil que puedes hacer con una petición como esta es simplemente mostrar todas las cabeceras de la respuesta. Esto te da la pauta de que es lo que tenes disponible a travez de las peticiones HEAD. El listing 10 provee una funcion de rellamada simple para exteriorizar todas las cabeceras de respuesta de una peticion HEAD.

Listing 10. Imprimir todas las cabeceras de respuesta de una petición HEAD

function updatepage(){
if (request.readyState == 4){
alert(request.getAllResponseHeader());
}
}

Controlar la figura 7, que muestra las cabeceras de respuestas de una aplicación simple que hace peticiones HEAD a un servidor.

Figura 7. Cabeceras de respuesta de una petición HEAD

Podés usar cualquiera de esas cabeceras (desde el tipo de servidor hasta el tipo de contenido) individualmente para dar información extra o funcionalidad dentro de una aplicación Ajax.
Controlar una URL
Ya has visto como controlar un error 404 cuando una URL no existe. Si esto se vuelve un problema comun --probablemente algún script o servlet este fuera de lineo cada tanto-- podrías querer controlar la URL antes de hacer una petición GET o POST completa. Para esto, haz una petición HEAD y luego controla el error 404 en tu funcion de rellamada; El listing 11 muestra una rellamada de muestra.

Listing 11. controlar si una URL existe

function updatePage(){
if (request.readyState ==4){
if (request.status==200){
alert ("Existe URL");
} else if (request.status ==404){
alert ("No existe la URL");
} else{
alert ("El estado es: " + request.status);
}
}
}

Para ser honestos, esto tiene poco valor. El servidor tiene que reponder la petición y resolver una respuesta para poblar el tamaño del contenido de la cabecera de respuesta, entonces no salvas nada de tiempo de procesamiento. Además, toma tanto tiempo hacer la petición y ver si la URL existe usando un petición HEAD que si lo hicieras usando GET o POST, solo estionando los errores como se muestra en el Listing 7. Aún así, a veces es útil saber exactamente que está disponible; nunca sabes cuando surgirá la creatividad y necesites la petición HEAD.
Peticiones HEAD útiles
Un área donde vas a encontrar útil la petición HEAD es para controlar el tamaño del contenido o también el tipo del contenido. Esto te permite determinar si tal cantidad de información va a ser devuelta para procesar la petición o si el servidor va a tratar de devolver información binaria en vez de HTML, texto o XML (los cuales son mucho mas fácil de procesar por JavaScript que la información binaria).
En esos casos, usas la cabecera apropiada y lo pasas al método getResponseHeader() del objeto XMLHttpRequest. Entonces para obtener el tamaño de una respuesta, solo llama al request.getResponseHeader("Content-Length");. Para obtener el tipo del contenido, usa request.getResponseHeader("Content-Type");.
En muchas aplicaciones, hacer peticiones HEAD no agrega funcionalidad y hasta poner lenta una petición (forzando una petición HEAD para obtener información sobre la respuesta y luego la petición GET o POST para obtener la respuesta propiamente dicha). Sin embargo, en el caso de que no estes seguro sobre un script o un componente del lado servidor, una petición HEAD puede permitirte obtener alguna información básica sin tener que lidiar con información de respuesta ni necesitas el ancho de banda para enviar esa respuesta.
En Conclusión
Para muchos programadores de Ajax y Web, el material en este artículo puede parecer bastante avanzado. ¿Cual es el valor de hacer una petición HEAD?¿Cual es realmente el caso donde deberías gestionar un codigo de estado de redireccionamiento explicito en tu JavaScript? Son buenas preguntas; para aplicaciones simples, la respuesta es que esas tecnicas avazadas probablemente no sean validas.
Sin embargo, la Web no es mas un lugar donde solo son toleradas aplicaciones simples; usuarios han vuelto más avanzados, los clientes esperan robustez y reportes de errores avanzados, y los directores son despedidos porque una aplicacion se cae un 1% del tiempo.
Es tu trabajo entonces, ir más allá de una simple aplicación y eso requiere una comprensión más profunda de XMLHttpRequest.

Si puedes explicar la variedad de estados ready --y comprender como se diferencian de navegador a navegador -- serás capas de eliminar errores de una aplicación rápidamente. Puede ser que incluso aparezcas con una creativa funcionalidad basada en los estados Ready y reportes un estado de la petcion a los usuarios y clientes.
Si tiene un manejo de los códigos de estados, podes fijar tu aplicación para que maneje los errores en el script, las respuestas inesperadas y los casos límite. Como resultado, tu aplicación va a trabajar todo el tiempo, mas que solo en llas situaciones en que todo está bien.
Agregas a hesta habilidad el hacer peticiones HEAD, controlar la existencia de una URL, y descubrir cuando un archivo fue modificado y puede asegurar que los usuarios acceden a páginas validas, estan actualizados en su información y (lo más importante) los sorprendes con solo lo robusta y versatil que es tu aplicación.

Este artículo no va a hacer tus aplicaciones llamativas, ayudarte a resaltar el texto con luces amarillas que se devanecen, o que se sientan más como un escritorio. Mientras estas son todas fortalezas de Ajax (y temas que trataremos en próximos artículos) son en algun grado solo beneficios adicionales. Si podés usar Ajax para construir una sólido base en la cual tu aplicación maneje los errores y problemas suavemente, los usuarios van a volver a tu sitio y aplicación. Agregale a esto los trucos visuales de los que vamos a hablar en próximos artículos y vas a tener clientes emosionados, entusiasmandos y felices. (seriamente, no querrás perderte el próximo artículo!)

Traducción de Artículo de Ajax XVII

2006-05-31T18:21:00.000-03:00

Redireccionamientos y reenrutamiento
Antes de hablar en profundidad sobre errores, vale la pena hablar sobre algo que probablemente no hay que preocuparse cuando estas usando Ajax -- redireccionamientos. En los códigos de estado de HTTP, esta es la familia 300 de los códigos de estado, incluyendo:

301: Movido permanentemente
302: Encontrado (La petición fue redireccionada a otra URL/URI)
305: Usar Proxy (La petición debe usar proxy para acceder al recurso solicitado)

los programadores de Ajax probablemente no están preocupados por los redireccionamientos por dos razones:

Primero, las aplicaciones ajax siempre se escriben para un script, servlet o aplicación del lado-servidor especifico. Para que ese componente desaparesca y sea movido a otro lado sin que vos, el programador de ajax, te enteres es un poco extraño. Entonces, más a menudo que no, vas a saber que ese recurso fue movido (por que lo moviste), cambias la url en tu petición y nunca te encuentras con este tipo de resultados.
y la razon las relevante es: Las aplicaciones Ajax tiene sandbox. esto significa que el dominio que sirve a una página Web que hace peticiones Ajax es el dominio que tiene que responder a esas peticiones. Por esto una pagina web servida por ebay.com no puede hacer una peticion de estilo Ajax a un script que se ejecuta en amazon.com; Aplicaciones Ajax en ibm.com no pueden peitcionar a los servlets que se ejecutan en netbeans.org

Como resultado, tus peticiones no pueden ser redirecciondas a otro servidor sin generar un error de seguridad. En esos casos, no vas a recibir un código de estado. Normalmente solo vas a tener un error JavaScript en la consola de debug. Por esto, mientras que piensas en un montón de códigos de estado, puedes ignorar en gran parte los códigos de redireccionamiento en conjunto.

Casos límite y casos difíciles
En este punto, los programadores principiantes se preguntaran qué es todo este lio. Es cierto que menos del 5% de las peticiones Ajax requieren trabajar con los estados ready 2 y 3 y los códigos de estados como el 403 (de hecho, sería más cercano al 1% o menos). Estos casos son importantes y se llaman casos límites -- ocurren en situaciones muy inusuales en las cuales se desarrollan las condiciones más extrañas. Apesar de ser inusuales los casos límites probocan alrededor de 80% de las frustraciones de los usuarios!
Los usuarios típicos de olvidan de las 100 veces que una aplicación funciona correctamente pero recuerdan claramente la vez que no lo hace. Si podes manejar los casos límite -y los casos dificiles-suavemente, entonces vas a tener contenidos a los usuarios que volveran a tu sitio.

Errores
Una vez que hayas tenido cuidado con el código de estado 200 y te hayas dado cuenta de que podes ignorar rotundamente la familia de códigos de estado 300, el otro grupo de códigos que queda para preocuparse es la familia 400, que indica varios tipos de error. Mirar de nuevo el listin 7 y notar que mientras se manejan los errores, solamente se muestra al usuario un mensaje de error genérico. Mientras este es un paso en la direccion corretam, es aun un mensaje bastante inutil a losefectos de decirle al usuario o programador que está trabajando en la aplicación que es lo que realmente esta mál.
Primero, agregar soporte a las paginas perdidas. Esto no pasa mucho en los sistemas de producción, pero no es raro en pruebas para mover un script o que un programador ingrese una URL incorrecta. Si podes reportar los errores 404 con gracia, vas a proveer mucha mas ayuda a los usuarios y programadores confundidos. Por ejemplo, si un script en el servidor fue removido y usas el codigo en el listing 7, verías un error no descriptivo como el que se muestra en la figura 5.

Figura 5. Manejo de error genérico

El usuario no tiene manera de decirte si el problema es de autenticación, o un scrip perdido (que es el caso acá), o un error de usuario, o más si algo en el código causó el problema o no. Un poco de código simple adicional puede hacer este error mucho más especifico. Hechale una ojeda al listing 8 que trata los script perdidos, así como errores de autenticación con un mensaje especifico.

Listing 8. Controlar el código de estado válido

function updatePage(){
if (request.readyState == 4){
if (request.status == 200){
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML = response[1].replace)/\n/g, "<br /&g;");
} else if (request.status == 404){
alert ("No se encontro URL solicitada.");
}else if (request.status == 403){
alert ("Acceso denegado.");
}else
alert ("El estado es " + request.status);
}
}

Esto es todavía bastante simple, pero provee algo de información adicional. La figura 6 muestra el mismo error que en la figura 5, pero esta vez el código tratador de error da una mucho mejor imagen de que esta pasando al usuario o programador.

Figura 6. Gestión de error especifica.

En tus propias aplicaciones, podrias considerar despejar el nombre de usuario y la contraseña cuando ocurre una falla de autenticación y agregar un mensaje de error a la pantalla. Pueden ser aplicadas mejoras similares para una gestion mas amigable de los script perdidos u otros errores tipo 400 (tal como el 405 para un método de petición inaceptable como enviar una petición HEAD que no está permitida o 407 en la que se requiere autenticacion de proxy). Cuaquier elección que hagas, empieza con la gestión del código de estado devuelto por el servidor.

Traducción de Artículo de Ajax XVI

2006-05-29T21:56:00.000-03:00

Conseguir datos seguros
Toda la documentación y especificaciones insiten en que solamente cuando el estado ready esta en 4 la información es segura para usar. Creeme, rara vez encontraras un caso donde la información no pueda ser obtenida de la propiedad responseText cuando el estado ready está en 3. Sin embargo, confiar en eso en tu aplicacion es una mala idea -- desde el momento que escribis código que dependa de información completa con estado ready en 3, está casi garantizado que llegará el momento en que la información sea incompleta.
Una mejor idea es proveer al usuario de alguna información cuando el estado ready este en 3, que una respuesta esta proxima. Mientras que usar una funcion como alert() es obviamente una mala idea --usar Ajax y luego bloquear al usuario con un cuadro de dialogo de alerta es muy poco razonable -- podes actualizar un campo en tu formulario o página mientras los estados ready cambian. Por ejemplo, trata de establecer el ancho de un indicador de progreso a un 25% para el estado ready en 1, 50% para el 2, 75% para el 3 y 100% (completo) cuando el estado ready llega a 4.
Por supuesto, como has visto, esta mejora es inteligente pero navegador-dependiente. En Opera, nunca obtendrás esos dos primeros estados ready y en Safari salta el primero (1). Por esa razón, dejo el codigo como este como ejercicio antes que incluirlo en el articulo.
Tiempo de echar un vistaso a los códigos de estado.
Una mirada mas cercana a los códigos de estado de HTTP
Con los estados READY y la respuesta del servidor en tu bolsa de técnicas de programación de Ajax, etas listo para agregar otro nivel de la sofisticación a tus aplicaciones Ajax --trabajar con códigos de estado del HTTP. Estos códigos son nada nuevo a Ajax. Han estado alrededor de la Web siempre que hubo Web. Ya has visto probablemente varios de éstos con tu navegador web:

401: Sin autorizacion
403: Prohibido
404: No encontrado

Podes encontrar mas (Para una lista completa, ver Resources). Para agregar otra capa de control y sensibilidad (y particularmente un manejor de error más robusto) a tus aplicaciones Ajax, entonces necesitas comprobar los códigos de estado en una petición y responder apropiadamente.

200: Todo está Bien

En muchas aplicaciones Ajax, vas a ver una funcion de rellamada que controla el estado ready y luego continuan trabajando con la información de la respuesta del servidor, como en el listing 6.

Listing 6. Funcion de rellamada que ignora el codigo de estado

function updatePage(){
if(request.readystate ==4){
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML = response[1].replace(/\n/g, "<br />");
}
}

Esto resulta ser una mejora miope y propensa a error en programacion Ajax. Si un script requiere autentificación y tu peticion no provee credenciales validas, el servidor va a devolver un código de error como el 403 o 401. Sin embargo, el estado ready va a estar establecido en 4 ya que el servidor respondió la petición (a pesar de que la respuesta no sea la que querias o esperabas para tu petición). Como resultado, el usuario no va a obtener información valida y hasta podría obtener un error feo cuando tu JavaScript trate de usar una unformación del servidor no existente.
Toma un esfuerzo minimo asegurarse que el servidor no solo haya terminado con una petición, sino que haya devuelto un código de estado "todo esta bien". Ese código es "200" y se reporta a traves de la propiedad status del objeto XMLHttpRequest. Para estar seguro de que no solo el servidor haya terminado con una petición sino que también reporte un estado ok, agrega un control adicional en tu función de rellamada como se muestra en el listing 7.

Listing 7. Controlar el código de estado válido

function updatePage(){
if (request.readyState ==4) {
if (request.status == 200){
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML = response[1].replace(/\n/g,"<br />");
} else
alert ("el estado es " + request.status);
}
}

Con la adición de algunas líneas del código, podes estar seguro de que si algo sale mal, tus usuarios van a obtener un (custionablemente) útil mensaje de error antes que ver una pagina con información mutilada sin explicación alguna.

Traducción de Artículo de Ajax XV

2006-05-29T16:57:00.000-03:00

Inconsistencia de navegadores
Una vez que tenes un entendimiento básico de este proceso, trata de acceder desde varios navegadores diferentes. Deberías notar algunas inconsistencias en como estos estados ready son manipulados. Por ejemplo en Firefox 1.5, ves los siguientes estados ready:

Esto no debería ser una sorpresa ya que todos los estados están representados acá. Sin embargo si accedes la misma aplicación usando Safari, deberías ver --o mas, no ver-- algo interesante. Acá están los estados que ves en Safari 2.0.1

Safari realmente deja afuera el primer estado ready y no hay una explicación sensata de porqué; es simplemente la manera en que trabaja Safari. Esto ilustra también un punto importante: mientras es una buena idea asegurar que el estado Ready de una petición sea 4 antes de usar la información del servidor, escribir código que dependa de cada cambio del estado ready es una manera segura de obtener resultados distintos en navegadores distintos.
Por ejemplo, cuando se usa Opera 8.5, las cosas son todavía peores con la salida de los estados ready:

Por último pero no menos, Internet Explorer responde con los siguientes estados:

Si tienes problemas con una petición, este es el primer lugar para buscar los problemas. Agrega un alerta para mostrar el estado ready de tu petición para que puedas asegurarte de que las cosas estan operando correctamente. Mejor todavía, prueba en Internet Explorer y Firefox--vas a obtener los 4 estados readyy vas a poder controlar cada etapa de la petición.
Luego yo miro el lado de la respuesta.
Información de respuesta bajo el microscopio
Una vez que entiendas los varios estados ready que ocurren durante una petición, estás listo para mirar otra pieza importante del objeto XMLHttpRequest --la propiedad responseText. Recuerda del último artículoque esta es la propiedad usada para obtener la información del servidor. Una vez que el servidor ha terminado de procesar la petición, situa toda información que se necesita para responder la petición en el responseText de la petición. Luego tu función de rellamada puede usar esa información, como se ve en el listing1 y 4.

Listing 4. Usar la respuesta del servidor

function updatePage() {
if(request.readyState == 4) {
var newTotal = request.responseText;
var totalSoldEl = document.getElementById("total-sold");
var netProfitEl = document.getElementById("net-profit");
replaceText(totalSoldEl, newTotal);
/*Descubrir la nueva ganancia neta*/
var boardCostEl = document.getElementById("board-cost");
var boardCost = getText(boardCostEl);
var manCostEl = document.getElementById("man-cost");
var manCost = getText(manCostEl);
var profitPerBoard = boardCost - manCost;
var netProfit = profitPerBoard * newTotal;
/*Actualizar la ganancia neta el el formulario de ventas*/
netProfit = Math.round(netProfit *100)/100;
replaceText (netProfitEl, netProfit);
}
}

El Listing 1 es bastante simple; el Listing 4 es un poco mas complicado, pero para empezar, ambos controlan el estado ready y luego toman el valor (o valores) de la propiedad responseText.
Visualizar el texto de respuesta durante una petición
Como el estado ready, el valor de la propiedad responseText cambia durante el ciclo de vida de la petición. Para ver esto en acción, usa el código como el que se muestra en el listing 5 para probar el texto de respuesta de una petición, tal como los estados ready.

Listing 5. Probar la propiedad responseText

function updatePage(){
//Mostrar el estado ready actual
alert("updatePage() llamada con el estado ready en " + request.readyState + " y un texto de respuesta de '" + request.responseText + "'");
}

Ahora abre tu aplicación Web en un navegador y activa tu petición. Para obtener lo maximo de este código, usa Firefox o Internet Explorer ya que estos navegadores reportan todos los estados posibles durante una petición. Con un estado ready en 2, por ejemplo, la propiedad responseText es indefinida (ver figura 3) y deberías ver un error si la consola JavaScript está abierta tambien.

Figura 3. Texto de respuesta con un estado ready en 2

Con el estado ready en 3 sin embargo, ha colocado un valor en la propiedad responseText, al menos en este ejemplo (ver figura 4).

Figura 4: Texto de respuesta con un estado ready en 3

Vas a descubrir que tu respuesta en el estado ready 3 varía de scritp a script, servidor a servidor y navegador a navegador. SIn embargo esto aun es increiblemente util para eliminar errores de tu aplicación.

Traducción de Artículo de Ajax XIV

2006-05-29T11:08:00.000-03:00

Dominar AJAX, Parte 3: Peticiones y respuestas Avanzandas en AJAX
Ganar una comprensión completa de los códigos de estado de HTTP, de los estados READY, y del objeto de XMLHttpRequest
Nivel: Introductorio
Brett McLaughlin (brett@oreilly.com), Autor y Editor, O´Reilly y Asociados.
14 Feb 2006

Para muchos desarrolladores Web, hacer peticiones simples y recibir respuestas simples es todo lo que siempre necesitaron, pero para desarrolladores que quieran dominar Ajax, se requiere un entendimiento completo de códigos de estado de HTTP, estados Ready y el objeto XMLHttpRequest. En este artículo Brett McLaughlin te va a mostrar los diferentes códigos de estado y va a demostrar como los maneja cada navegador y va a mostrar peticiones menos usadas que se pueden hacer con Ajax

En el último artículo de esta serie, proporcioné una sólida introducción al objeto XMLHttpRequest, la pieza central de una aplicación Ajax que maneja peticiones para aplicaciones o scripts del lado servidor y tambien trata con información devuelta por ese componente del lado servidor. Toda aplicación Ajax usa el objeto XMLHttpRequest, por eso vas a querer estar intimamente familiarizado con él, para realizar tus aplicaciones Ajax y para realizarlas bien.
En este artículo, me muevo más allá de los fundamentos del artículo pasado y me concentro más en detalle sobre tres parte claves de este objeto de petición:

Los estados Ready de HTTP
Los códigos de estado de HTTP
Los tipos de peticiones que podes hacer

Cada uno de estos es considerado generalmente parte de la cañería de una petición; como resultado, poco detalle se registra sobre estos temas. Sin embargo vas a necesitar ser fluido en estados Ready, códigos de estado, y peticiones si querés hacer mas que solo salpicar en programación Ajax. Cuando algo anda mal en tu aplicación -- y las cosas siempres andan mal-- entender estados Ready, como hacer una petición de cabeceras o que significa un código de estado 400 puede hacer la diferencia entre 5 minutos de eliminar errores y 5 horas de frustración y confusión.
Miraré estados READY de HTTP primero.
Introduciendonos mas profundo en los estado ready de HTTP
Debés recordar del articulo anterior que el objeto XMLHttpRequest tiene una propiedad llamada readyState. Esta propiedad asegura que un servidor ha completado una petición y típicamente una función de rellamada usa la informacion del servidor para actualizar un formulario web o página. El listing 1 muestra un ejemplo simple de esto (también en el último artículo de la serie)

Listing 1.Tratar con una respuesta del servidor en una funcion de rellamada.

function updatePage(){
if(request.readyState==4){
if (request.status==200){
var response = request.responseText.split("|");
document.getElementById("order").value=response[0];
document.getElementById("address").innerHTML=response[1].replace(/\n/g."<br />");)
} else
alert ("El estado es " + request.status);
}
}

Este es definitivamente el uso más común (y el mas simple) de los estado ready. Como seguramente adivinaras por numero "4", hay varios otros estado ready (tambien viste esta lista en el último artículo):

0: La petición no está inicializada (antes de llamar a la funcion open()).
1: La petición esta establecida pero no enviada (antes de que hayas llamado a send()).
2: La petición fue enviada y está en proceso (podes normalmente obtener los contenidos de cabecera de la respuesta en este punto)
3: La petición está en proceso , a veces alguna información parcial está disponible de la respuesta, pero el servidor no ha terminado con esa respuesta.
4: La respuesta esta completa, podes tomar la respuesta del servidor y usarla.

Si deseas ir mas alla de los fundamentos de la programación en Ajax, necesitas saber no solo estos estados sino cuando ocurren y como podes usarlos. Sobre todo, necesitas aprender en qué estado de una petición encuentras cada estado READY. Desafortunadamente, esto es bastante poco intuitivo y también implica algunos casos especiales.
Estados ready ocultos
El primer estado ready, identificado por la propiedad del readyState 0 (readyState== 0), representa una petición no inicialidada. Tan pronto como llames a open() en tu objeto petición, esta propiedad se establece a 1. Como casi siempre llamas a open() tan pronto como inicializas tu petición, es raro ver readyState==0. Es más el estado ready sin inicializar es bastante inútil en aplicaciones prácticas.
No obstante, en el interés de ser completo, comprobar en el listing 2 que demuestra cómo conseguir el estado READY cuando es 0.

Listing 2. Obtener el estado ready 0

function getSalesData() {
//crear el objeto petición
createRequest();
alert("El estado Ready es " - request.readyState);
//Establecer (inicializar) la petición
var url = "/boards/servlet/updatePage";
request.send(null);
}

En este ejemplo simple, getSalesData() es la función que tu página Web llama para empezar una petición (como cuando un botón es presionado). Observar que tienes que comprobar el estado READY antes de que se llame a open() . La figura 1 demuestra el resultado de ejecutar esta aplicación.

Figura 1: Un estado ready en 0

Obviamente, esto no te hace mucho de bueno; hay muy pocas veces en que necesitarás cerciorarse de que open() no se haya llamado. El único uso para este estado READY en el casi-verdadero-mundo de programación de Ajax es si haces peticiones múltiples usando el mismo objeto de XMLHttpRequest a través de funciones múltiples. En esa situación (algo inusual), puede ser que desees asegurarse de que un objeto de la petición esté en el estado sin inicializar( readyState== 0) antes de hacer nuevas peticiones. Esto esencialmente se asegura de que otra función no esté utilizando el objeto al mismo tiempo.

Cuando 0 es igual a 4
En el caso de uso donde las funciones múltiples de Javascript utilizan el mismo objeto de petición, comprobar si hay un estado READY en 0 para asegurarse de que el objeto de la peticiónno esté en uso puede resultar ser problemático. Puesto que el readyState== 4 indica una petición terminada, encontrarás a menudo los objetos depetición que no se están utilizando con su estado READY todavía fijado en 4 -- los datos del servidor fueron utilizados, pero nada ha ocurrido desde entonces para reajustar el estado READY. Hay una función que reajusta un objeto de la petición llamado abort(), pero realmente no fue pensada para este uso. Si tenes que utilizar funciones múltiples, puede ser que sea mejor crear y utilizar un objeto de petición para cada función más que compartir el objeto a través de funciones múltiples.

Ver el estado READY de una petición en curso
Aparte del estado READY en 0, tu objeto de petición debe pasar con cada uno de los otros estados READY en una petición y respuesta típica, y finalmente terminar con un estado READY de 4. Éso es cuandola línea if(request.readyState == 4) del código que ves en la mayoría de las funciones de rellamada entra; asegura que el servidor terminó y es seguro actualizar la página Web o tomar una acción basada en la información del servidor.
Es una tarea trivial realmente ver este proceso tal como ocurre. En vez de solamente de ejecutar el código en tu rellamada si el estado READY es 4, solamente muestra el estado READY cada vez que tu rellamada sea llamada. Como ejemplo del código que hace esto, comprobar el listing 3.

Listing 3. Comprobar el estado Ready

function updatePage(){
//mostrar el estado Ready actual
alert("updatePage() llamado con un estado ready en " + request.readyState);
}

Si no estás seguro de cómo conseguir este funcionamiento, necesitarás crear una función para llamar desde tu página Web y para hacer que envíe una petición a un componente del lado servidor (tal como la función que fue demostrada en el listing 2 y a través de los ejemplos en el primero y segundo artículos en esta serie). Cerciorarte de que cuando estableciste tu petición, fijaras la función de rellamada al updatePage (); para hacer esto, fijar la propiedad onreadystatechange de tu objeto petición al updatePage ().
Este código es una gran ilustración de exactamente qué significa el onreadystatechange -- el estado READY de la petición cambia cada vez, se llama el updatePage () y ves una alarma. Figura 2 demuestra un ejemplo de esta función siendo llamada, en este caso con un estado READY de 1.

Figura 2 Un estado ready en 1

Probá este código vos mismo. Ponelo en tu página Web y luego activá tu evento (presionar un botón, salir de un campo con Tab, o cualquier metodo que hayas establecido como disparador el una petición). Tu función de rellamada se va a ejecutar varias veces -- cada vez que el estado ready de la petición cambie-- y vas a ver un alerta por cada estado ready. Esta es la mejor manera de seguir una petición en cada una de sus etapas.

Traducción de Artículo de Ajax XIII

2006-05-29T10:20:00.000-03:00

En Conclusión
Ya estarás un poco cansado del XMLHttpRequest --rara vez leo un artículo entero sobre un solo objeto, especialmente uno que es tan simple. Sin embargo, vas a usar este objeto una y otra vez en cada página y aplicación que escribas donde uses Ajax. En verdad, todavía queda algo por decir sobre XMLHttpRequest. En próximos artículos, vas a aprender a usar POST ademas de GET en tus peticiones, establecer y leer contenidos de cabeceras en tus petición así como en la respuesta del servidor; vas a entender como codificar tus peticiones y también menjar XML en tu modelo petición/respuesta.
Un poco mas adelante vas a ver también algunos de los cajas de herramientas populares que están disponibles. Estas cajas de herramientas abstraen realmente la mayor parte de los detalles discutidos en este artículo y hacen la programación de Ajax más fácil. Puede ser que incluso te preguntes porqué tenés que códificar todo este detalle de bajo nivel cuando las cajas de herramientas estan tan fácilmente disponibles. La respuesta es, él es terriblemente durodarse cuenta que está mal en tu aplicación si no entendes qué está pasando en tu aplicación.
Por eso no ignores estos detalles o pases rapidamente por ellos; cuando tu práctico-excelente caja de herramientas crea un error, te no detengas racando tu cabeza y mandando un email a la ayuda. Con una comprensión de cómo utilizar XMLHttpRequest directamente, encontrarás fácil eliminar errores y arreglar incluso los problemas más extraños. Las cajas de herramientas están muy bien a menos que cuentes con ellas para resolver todos tus problemas.
Entonces ponete con XMLHttpRequest. De hecho, si tienes en funcionamiento código de Ajax que utilice una caja de herramientas, intenta reescribirla usando solo el objeto XMLHttpRequest y sus propiedades y métodos. Será un gran ejercicio y te ayudará probablemente a entender qué está pasando mucho mejor.
En el artículo siguiente, indagarás incluso más profundo en este objeto, explorando algunas de sus características particulares (como responseXML), así como tambien cómo utilizar peticiones POST y enviar datos en diversos formatos. Entonces empezá a codificar y chequée acá en alrededor de un mes.

Traducción de Artículo de Ajax XII

2006-05-29T04:49:00.000-03:00

Códigos de estado del HTTP
A pesar del exito aparente en el código del listing 12, todavía hay un problema -- que pasa si el servidor responde a tu petición y termina de procesar, pero reporta un error? Recuerda, el código del lado servidor debería tener en cuenta si esta siendo llamado por Ajax, JSP, un formulario HTML común, o cualquier otro tipo de código; solo tiene los métodos especificos Web tradicionales de reportar información. Y en el mundo Web, códigos HTTP pueden tratar con varias cosas que pueden pasar en una petición.
Por ejemplo, has ingresado una petición para una URL, escribis mal la URL, y recibes un código de error 404 que indica que la página está perdida. Este es uno de tantos códigos de error que una petición HTTP puede recibir como estatus (ver Recursos por un link a una lista completa de códigos de estado). 403 y 401, ambos indican información segura u prohibidaesta siendo accedida, también son comunes. En cada uno de esos casos, son códigos que resultan de una
respuesta completa. En otras palabras, el servidor completa la petición (significa que el estado ready es 4), pero es probable que no devuelva la informacion deseada por el cliente.
Además del estado ready, tambien necesitas chequear el estado HTTP. Estas buscando al código de estado 200 que simplemente significa correcto. Con un estado ready 4 y un código de estado de 200, estas listo para procesar la información del servidor y esa información debería ser lo que pediste (y no un error u otro tipo de información problemática). Agrega otro control de estado a tu método de rellamado como se muestra en el listing 14.

Listing 14. Controlar el código de estado HTTP

function updatePage() {
if (request.readyState == 4)
if (request.status == 200)
alert("Server is done!");
}

Para agregar un manejo de error más robusto --con minimas complicaciones-- deberias agregar un control o dos para otros códigos de estado; ver la version modificada de updatePage() en el listing 15.

Listing 15. Agregar algún control de error liviano.

function updatePage() {
if (request.readyState == 4)
if (request.status == 200)
alert("Server is done!");
else if (request.status == 404)
alert("Request URL does not exist");
else
alert("Error: status code is " + request.status);
}

Ahora cambiar el URL en tu getCustomerInfo() a una URL no existente y vean que pasa. Deberias ver una alerta que te diga que el URL que solicitaste no existe -- perfecto! Dificilmente vaya a controlar toda condición de error, pero en una cambio simple que cubre el 80% de los problemas que pueden ocurrir en una típica aplicación Web.

Leer el texto de respuesta
Ahora que te aseguraste de que la petición fue procesada completamente (a traves del estado ready) y el servidor te da una respuesta normal y lista (a traves de el código de estado), podes finalmente trabajar con la información devuelta por el servidor. Esta es convenientemente almacenada en la propiedad responseText del objeto XMLHttpRequest.
Detalles sobre como se ve el texto en responseText, en terminos de formato o tamaño, es intensionalmente vago. Esto permite al servidor establecer este texto a virtualmente cualquier cosa. Por ejemplo, un script puede retornar valores separados con coma, otro valores separados con pipe (el pipe es el caracter |) y otro podria retornar una larga cadena de texto. Todo está en el servidor.
En el caso del ejemplo usado en este artículo, el servidor devuelve la última orden del cliente y luego su dirección, separadas por el simbolo |. La orden y la dirección son usados para establecer los valores de elementos en el fomulario; el listing 16 muestra el código que actualiza la pantalla.

Listing 16. tratar con la respuesta del servidor.

function updatePage(){
if(request.readyState==4){
if(request.status ==200) {
var response = request.responseText.split("|");
document.getElementById("order") .value = response[0];
document.getElementById("adress").innerHTML =
response[1].replace(/\n/g,"
");
}else
alert("el estado es "+request.status);
}
}

Primero, el responseText es extraido y separado en los simbolos | usando el metodo JavaScript split(). El arreglo de valores resultante, es volcado en response. El primer valor --la última orden del cliente-- se accede en el arreglo como response[0],y es establecido como el valor del campo con un ID "orden". El segundo valor en el arreglo, en response[1] es la dirección del cliente y requiere un poco más de procesamiento. Como las lineas en la direccion están separadas por separadores de linea normales (el caracter \n), el código necesita remplazar estas con separadores de lineas estilo XHTML, <br />s. Esto se realizo a traves del uso de la funcion replace() junto con una expresion regular. Finalmente, el texto modificado se establece como el HTML interior de un div en el fomulario HTML. El resultado es que el formulario es actualizado de repente con la información del cliente, como puedes ver en la figura 4.

Antes de concluir, otra propiedad importante del XMLHttpRequest se llama responseXML. Esta propiedad contiene (podes adivinar?) una respuesta XML en el evento de donde el servidor elija responder con XML. Trabajar con una respuesta XML es un tanto distinto que trabajar con una repuesta de texto plano, e involucra análisis, el Modelo de Objetos de documento (DOM) y otras varias consideraciones. Vas a aprender más sobre XML en un artículo futuro. Además, por que responseXML comunmente aparece en discuciones alrrededor de responseText, vale la pena mencionarlo acá. Para muchas aplicaciones simples de Ajax es todo lo que necesitas, pero pronto vas a aprender a manejar XML a travez de aplicaciones Ajax también.

Traducción de Artículo de Ajax XI

2006-05-22T07:59:00.000-03:00

Manipulación de respuestas del servidor
Hiciste tu petición, tu usuario esta trabajando felizmente en el formulario Web (mientras el servidor tranaha en la petición), y ahora el servidor termina de tratar la petición. El servidor se fija en la propiedad onreadystatechange y detecta que método llamar. Una vez que eso ocurre, podes pensar en tu aplicación como en cualquier otra, asincrónica o no. En otras palabras, no tenes que tomar ninguna acción especial escribiendo métodos que respondan al servidor; solo cambiá el formulario, enviá al usuario a otra URL o hacé lo que necesites con la respuesta del servidor. En esta sección nos centraremos en responder al servidor y luego tomar una acción típica --cambiar al vuelo parte del formulario que ve el usuario.
Rellamadas y Ajax
Ya viste como hacer saber al servidor que hacer cuando termina: fijar la propiedad onreadystatechange del objeto XMLHttpRequest al nombre de la funcion a ejecutar. Luego, cuando el servidor haya procesado la petición, va a llamar automaticamente esa función. Tampoco necesitás preocuparte de ningún parámetro para ese método. Vas a empezar con un método simple como en el Listing 12.

Listing 12. Código del método de rellamada

<script language="javascript" type="text/javascript">
var request = false;
try {
request = new XMLHttpRequest();
} catch (trymicrosoft) {
try {
request = new ActiveXObject("Msxml2.XMLHTTP");
} catch (othermicrosoft) {
try {
request = new ActiveXObject("Microsoft.XMLHTTP");
} catch (failed) {
request = false;
}
}
}
if (!request)
alert("Error al inicializar XMLHttpRequest!");
function getCustomerInfo() {
var phone = document.getElementById("phone").value;
var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
request.open("GET", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}

function updatePage() {
alert("El servidor terminó!");
}
</script>

Esto solo dispara una alerta útil, para decirte cuando termina el servidor. Prueba este código en tu propia página, guarda la página y luego tirala en un navegador (si queres XHTML de este ejemplo, ver el listing 8) cuando ingreses un número de teléfono y dejes el campo, deberías ver la ventana de alerta (ver figura 3); pero si presionás OK va a aparecer otra vez... y otras.

Figura 3: Código de Ajax mostrando una ventana de alerta

Dependiendo de su navegador, vas a tener dos, tres, o aún cuatro alarmas antes de el formulario pare de mostrar alarmas. ¿Qué se está pasando? Resulta que no has considerado el estado ready del HTTP, un componente importante del ciclo de peticion/respuesta.
Estados ready de HTTP
Antes, dije que el servidor, una vez que termina con una petición, busca qué método llamar en la propiedad onreadystatechange de XMLHttpRequest. Eso es verdad, pero no es toda la verdad. De hecho, llama a ese método cada vez que el estado READY del HTTP cambia. ¿Qué significa? Bien, tenes que entender los estados READY del HTTP primero.
Un estado READY del HTTP indica el estado o situacion de una petición. Se utiliza para reconocer si se ha comenzado una petición, si se está contestando, o si el modelo de petición/respuesta ha terminado. Es también útil en la determinación de si es seguro leer cualquier texto o datos de la respuesta que un servidor pudo haber provisto. Necesitas saber sobre los cinco estados READY en tus aplicaciones Ajax.

0: La petición está sin inicializar (antes de que hayas llamado a open())
1: La petición esta seteada, pero no ha sido enviada (antes de que hayas llamado a send())
2: La petición fue enviada y está siendo procesada (normalmente podes obtener el contenido cabecera de la respuesta a este punto)
3: La petición está siendo procesada; a menudo alguna informacion parcial de la respuesta está disponible, pero el servidor todavía no ha terminado con esa respuesta.
4: La respuesta está completa; podes tomar la respuesta del servidor y usarla.

Como la mayoria de los asuntos de multi-navegador, estos estados ready son usados un poco incosistentemente. Esperarias ver siempre los estados ready moverse desde 0 a 1 a 2 a 3 a 4, pero en la práctica, es raramente el caso. Algunos navegadores nunca reportan 0 o 1 y saltan directamente al 2, después al 3 y luego al 4. Otros navegadores reportan todos los estados. Ademas otros van a reportar el estado 1 varias veces. Como ves en la ultima sección, el servidor llama al updatePage() varias veces, y cada invocación resulta en una caja de alerta mostrandose --probablemente no como querías!
Para la programación Ajax, el unico estado con el que necesitas tratar es el estado ready 4, que indica que la respuesta del servidor está completa y es segura para ver la información de respuesta y usarla. A cuenta de esto, la primera línea en el método de rellamada deberia ser como se muestra en el listing 13

Listing 13. Check the ready state

function updatePage() {
if (request.readyState == 4)
alert("Server is done!");
}

Este cambio comprueba para asegurarse de que el servidor realmente haya acabado con el proceso. Intenta ejecutar esta versión del código Ajax y solamente deberías obtener el mensaje alerta una vez, que es como debe ser.

Traducción de Artículo de Ajax X

2006-04-18T18:31:00.000-03:00

Especificando un metodo de rellamada
En este punto has hecho bastante poco que se sienta como nuevo, revolucionario o asincronico. Concedido, esa pequeña clave "true" en el método open() establece una peticion asincronica. Pero ademas de eso, este codigo se parece a la programacion con servlets Java y JSPs, PHP o Pearl. Entonces, ¿cuál es el gran secreto de Ajax y Web 2.0? EL secreto da vueltas sobre una simple propiedad de XMLHttpRequest llamada onreadystatechange.
Primero asegurate de que entiendas el proceso que creaste en este código (revisa el listing 10 si lo necesitas). Una petición es seteada y luego hecha. Además, a causa de que esta es una peticion sincrónica, el método Javascript (getCustomerInfo() en el ejemplo) no va a esperar al servidor. Entonces el código va a continuar; en este caso, esto significa que el método va a salir y el control va a volver al formulario. Los usuarios pueden continuar ingresando información y la aplicación no va a esperar al servidor.
Esto crea una interesante pregunta, sin embargo: ¿qué pasa cuando el servidor termina de procesar la petición?. La respuesta, el menos tal como el código esta hasta ahora, es nada!. Obviamente, eso no es bueno, por eso el servidor necesita tener algún tipo de instrucción sobre que hacer cuando termine de procesar la peticion enviada a traves del XMLHttpRequest.
Aca es donde la propiedad onreadystatechange entra en juego. Esta propiedad te permite especificar un método de rellamada. Una rellamada permite al servidor (puedes adivinar) rellamar al código de tu página web.Le da un grado de control al servidor, tambien; cuando el servidor termina una petición, se fija en el objeto XMLHttpRequest y especificamente en la propiedad onreadystatechange. Cualquier método espsificado por esa propiedad es inbocado. Es una rellamada por que el servidor inicia una llamada de vuelta a la pagina Web --sin importar lo que este pasando en la pagina misma. Por ejemplo, podría llamar a este metodo mientras el usuario está sentado en su silla, sin tcar el teclado; sinembargo, tambien podría llamarlo cuando el usuario está tipeando, miviendo el mouse, moviendo la ventana, presionando un botón... no importa que esté haciendo el usuario.
Acá es realmente cuando la asincronicidad entra en juego: el usuario opera el formulario en un nibvel mientras en otro nivel, el servidor responde una petición y luego dispara el método de rellamada indicado por la propiedad onreadystatechange. Entonces necesitas especificar ese netodo en tu código como se muestra en el listing 11.

Listing 11. Establecer un metodo de rellamada
function getCustomerInfo(){
var phone = document.getElemntById("phone").value;
var url = "/cgi-local/lookupCustomer.php?phone="+escape(phone);
request.open("GET", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}

Poner especial atencion a donde en el código se fija esta propiedad --es antes de de la llamada send(). Tenes que fijar esta propiedad antes de que la petición sea enviada, así el servidor puede buscar la prpiedad cuando termine de responder una petición. Todo lo que nos queda es codificar el updatePage() que es el foco de la última sección de este articulo.

Traducción de Artículo de Ajax IX

2006-03-17T10:18:00.000-03:00

Un acertijo sobre asincronicidad
En un último artículo de esta serie, voy a tomarme un buen tiempo para escribir y usar código asincronico, pero deberías tener una idea de por que el último parametro en open() es tan importante. En un modelo normal de petición/respuesta -pensa en la Web 1.0 acá- el cliente (tu navegador o el código ejecutandose en tu maquina local) hace una petición al servidor. Esa petición es sincrónica, en otras palabras, el cliente espera por la respuesta del servidor. Mientras el clientes está esperando, normalmente ves una de las fomas de notificacion de que está esperando:

un reloj de arena (especialmente en windows)
Una pelota de playa giratoria (normalmente en máquinas Mac)
La aplicación se congela y a veces el cursor cambia.

Esto es lo que hace que las aplicaciones web en particular se sientan pesadas y lentas -- la ausencia de interactividad real. Cuando apretas un boton, tu aplicación se vuelve inutilisable hasta que la peticion que enviaste sea respondida. Si haces una peticion que requiera un importante procesamientos del servidor, la espera puede ser significativa (al menos para los multiprocesadores, DSL , mundo sin espera de hoy).
Una petición asincrónica sin embargo, no espera a que el servidor responda. Mandas la petición y luego tu aplicación continúa. Los usuarios pueden cargar información al formalario todavía, presionar otros botones, y hasta dejar el formulario. No hay pelota de playa giratoria o reloj de arena girando y no hay grandes congelamientos de la aplicacion. El servidor responde silenciosamente y cuando termina, le hace saber al solicitante original que ya está hecho (de maneras que verás en un momento). El resultado final es una aplicacion que no se siente pesada o lenta, al contrario es dinámica, interactiva y se siente mas rápida. Este es solo un componente de la Web 2.0, pero es muy importante. Todos los los componentes GUI pulidos y los paradigmas del diseño web no pueden superar un lento, sincrónico modelo de petición/respuesta.
Enviar la petición
Una vez configurada la peticion con open(), estás listo para enviarla. Afortunadamente el metodo para enviar una petición se llama de forma mas apropiada que open(); es llamado simplemente send().
send() tiene un solo parámetro, el contenido a enviar. Pero antes que penses mucho en eso, recuarda que estás listo para mandar informacion a traves de la URL misma:

var= url="/cgi-local/lookupcustomer.php?phone="+escape(phone);

Aunque podés mandar información usando send(), tambien podes mandarla a traves dela URL misma. De hecho, en las peticiones GET (que van a constituir tanto como el 80% de tu uso tipico de Ajax), es mucho mas facil mandar la informacion en la URL. Cuando empezas a mandar información segura o XML, es cuando queres ver como se manda contenido mediante send() (voy a hablar de ambos, informacion segura y envio de XML en uno de los ultimo sarticulos de esta serie). Cuando no necesitas pasar informacion atraves de send(), pasa null como argumento de este metodo. Entonces, para mandar una petición en el ejemplo que has visto en este artículo, eso es exactamente lo que se necesita. (ver listing10)

listing 10: enviar la peticion

function getCustomerInfo(){
var phone = document.getElementById("phone").value;
var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);
request.open("GET", url, true);
request.send(null);
}

Traducción de Artículo de AJAX VIII

2006-03-13T16:21:00.000-03:00

Enviar peticiones con XMLHttpRequest
Una vez que tenés tu objeto de petición, podés empezar el ciclo petición/respuesta. Recuerda, el único proposito de XMLHttpRequest es permitirtehacer peticiones y recibir respuestas. Todo lo demás -cambiar la interfaz del usuario, intercambio de imagenes, interpretar la información devuelta por el servidor- es trabajo de Javascript, CSS u otro código en tus paginas. Con XMLHttpRequest listo para usar, podes hacer una petición al servidor.
Bienvenido al cajón de arena1
Ajax tiene un modelo de seguridad sandbox. Como resultado, tu código Ajax (y especificamente, el objeto XMLHttpRequest) solamente puede hacer peticiones en el servidor en el cual esta ejecutandose. Vas a aprender mucho más sobre seguridad y Ajax en un artículo próximo, pero por ahora tené en cuenta que el código ejecutandose en tu máquina local solo puede hacer peticiones al los scripts del lado servidor en tu máquina local. Si tenés código Ajax ejecutandose en www.breakneckpizza.com, deberá hacer peticiones a los scripts que se ejecutan en www.breackneckpizza.com.
Establecer la URL del servidor
La primera cosa que necesitas determinar el la URL para conectarse con el servidor. Esto no es especifico de Ajax -obviamente ya tenes que saber como contruir una URL- pero es esencial para hacer una conexión. En la mayoria de las aplicacione, contruirias la URL con algo de información estática convinada con información del formulario con el que trabajan tus usuarios. Por ejemplo, el listing 7 muestrs algo de JavaScript que toma el valor del campo del número de teléfono y luego construye una URL usando esa información.

Listing 7. Construir una URL de petición

<script language="javascript" type="text/javascript">
var request = false;
try {
request = new XMLHttpRequest();
} catch (trymicrosoft){
try {
request=new ActiveXObject("Msxml2.XMLHTTP");
} catch(othermicrosoft) {
try {
request= new ActivexObject("Microsoft.XMLHTTP");
} catch (failed) {
request = false;
}
}
}
if (!request)
alert("Error al inicializar XMLHttpRequest!");

function getCustomerInfo(){
var phone = document.getElementById("phone").value;
var url = "cgi-local/lookupCustomer.php?phone=" + escape(phone);
}
</script>

Nada de esto debería confundirte. Primero, el código crea una nueva variable llamada phone y le asigna el valor del campo del formulario con el id igual a phone. El listing 8 muestra el XHTML para este formulario en particular donde podés ver el campo phone y su atributo id.

Listing 8. El formulario de Break Neck Pizza

<body>
<p><img src="breakneck-logo_4c.gif" alt = "Breack Neck Pizza" /></p>
<form action ="POST">
<p>
<input type = "text" size="14" name="phone" id="phone" onChange="getCustomerInfo();" />
</p>
<p>YOur order will be delivered to:</p>
<div id="address"></div>
<p>Type your order here</p>
<p><textarea name="order" rows="6" cols="50" id="order"></textarea></p>
<p><input type = "submit" value "Order Pizza" id="submit"/></p>
</form>
</body>

Tambien fijense que cuando el usuario ingresa su número de teléfono o lo cambia, dispara el método getCustomerInfo() mostrado en el listing 7. Ese método toma el numero y lo usa para construir una cadena URL, guardada en la variable URL. Recuerda, dado que el codigo Ajax tiene caja de arena y solo se puede conectar con el mismo servidor, no necesitarías el nombre deldominio en tu URL. En este ejemplo, el nombre del script es /cgi-local/lookupCustomer.php. Finalemnte, el número de teléfono es asociado a este script como un parámetro GET: "phone="+escape(phone).
Si no habías visto antes el método escape() , se usa para deschar todo caracter que no pueda ser enviado correctamente como texto. Por ejemplo, cualquier especio en el nuemro de telefono es convertido a los caracteres %20, haciendo posible el pasaje de los caracteres a traves de la URL.
Podes agregar tantos parametros como necesites. Por ejemplo, si queres agregar otro parametro, solo asocialo en la URL y separa los parametroscon el caracter ampersans & (el primer parametro es separado del nombre del script con un signo de pregunta ?)
Abriendo la petición
Con una URL para conectarse, podés configurar la petición. Lo logras usando el método open() de tu objeto XMLHttpRequest. Este método tiene tantos como 5 parámetros:

request-type: el tipo de petición a enviar. los valores tipicos son GET o POST, pero tambien podes mandar peticiones HEAD
url: LaURL para contectarse
asynch: Verdadero (true) que la petición sea asincrónica y falso (false) si tiene que ser una peticion sincrónica. Este parametro es opcional y por defecto es verdadero.
username: si se requiere autenticacion, podes especificar el nombre de usuario acá. Es un parametro opcional y no tiene valor por defecto.
password: si se requiere autenticacion, podes especificar la contraseña acá. Es un parametro opcional y no tiene valor por defecto.

Tipicamenter, vas a usar en primero de los tres. De hecho, hasta cuando quieras una peticion asincronica, deberías espesificar verdadero como tercer parametro. Ese es el valor por defecto , pero es un buen poco de auto-documentación para indicar si la peticion es asincronica o no.
Ponelo todo junto y normalemnte terminar con una linea que se ve como el listing 9:

Listing 9. Abrir la peticion
function getCustomerInfo(){
var phone = document.getElementById("phone").value;
var url = "cgi-local/lookupCustomer.php?phone=" + escape(phone);
request.open("GET", url, true);
}

Una vez que tenes la URL resulta, esto es bastante simple. Para la mayoria de las peticiones, usar GET es suficiciente (vas a ver situaciones en las cuales usarías post en articulos futuros); esto, junto con la URL, es todo lo que necesitas para usar open().

1. sandbox

Traducción de artículo de Ajax VII

2006-03-07T16:29:00.000-03:00

Estático versus dinámico
Fijate en los Listing 1, 3 y 4 y observá que todo el código está anidado directamente entre etiquetas script. Cuando JavaScript es codificado así y no puesto dentro un método o en el cuerpo de una función, se llama JavaScript estático. Esto significa que el código se ejecuta a veces antes que la página se muestre al usuario (no es 100% claro desde la especificación precisamente de cuando este código se ejecuta y los navegadores hacen diferentes las cosas; igual te garantiza que el código se ejecuta antes que los usuarios puedan interactuar con tu página). Es como generalmente la mayoría de los programadores de Ajax crean el objeto XMLHttpRequest.
Dicho esto, indudablemente podés poner este código en un método como se muestra en el listing 5

Listing 5. Mover el código de creación XMLHttpRequest dentro de un método

<script language="javascript" type="text/javascript">
var request;
function createRequest () {
try {
request = new XMLHttpRequest();
} catch (trymicrosoft){
try {
request=new ActiveXObject("Msxml2.XMLHTTP");
} catch(othermicrosoft) {
try {
request= new ActivexObject("Microsoft.XMLHTTP");
} catch (failed) {
request = false;
}
}
}
if (!request)
alert("Error al inicializar XMLHttpRequest!");
}
</script>

Con el código dispuesto como este, vas a necesitar llamar el método antes de que hagas algun trabajo Ajax. Entonces deberías tener algo como el listing 6

Listing 6. Usar un método de creación de XMLHttpRequest

<script language="javascript" type="text/javascript">
var request;
function createRequest () {
try {
request = new XMLHttpRequest();
} catch (trymicrosoft){
try {
request=new ActiveXObject("Msxml2.XMLHTTP");
} catch(othermicrosoft) {
try {
request= new ActivexObject("Microsoft.XMLHTTP");
} catch (failed) {
request = false;
}
}
}
if (!request)
alert("Error al inicializar XMLHttpRequest!");
}
function getCustomerInfo();
</script>

El único tema con este código - y la razón por la cual la mayorías de los programadores de Ajax no usan esta forma- es que retarda la notificación de error. Supongamos que tenés un formulario complejo con 10 o 15 campos, cajas de selección y similares, y disparas algo de código Ajax cuando el usuario ingresa texto en el campo 14 (al final del formulario). A ese punto, getCustomerInfo() se ejecuta, trata de crear un objeto XMLHttpRequest y (para este ejemplo) falla. Entonces se escupe un alerta al usuario, diciéndole (en varias palabras) que no puede usar esta aplicación Pero el usuario ya gastó su tiempo ingresando información en el formulario! Eso es bastante molesto y molestia no es algo que típicamente atraiga a los usuarios a volver a tu sitio.
En el caso donde usas JavaScript estático, el usuario va a ver un error apenas entre a la página. ¿eso es molesto tambien? Probablemente; puede hacer que los usuarios se enojen por que tu aplicacion no funciones en sus navegadores. Sin embargo, indudablemente es mejor que tirarle el mismo error despues de que se gastó 10 minutos ingresando información. Por esa sola razón, te propongo establecer tu códgo estaticamente e informarles a los usuarios de forma tamprana sobre posibles problemas.

Traducción de artículo sobre Ajax VI

2006-03-07T15:17:00.000-03:00

Introducción al XMLHttpRequest
Para hacer que esta maravilla suceda, necesitás familiarizarte íntimamente con un objeto JavaScript llamado XMLHttpRequest. Este pequeño objeto -que realmente ha estado en varios navegadores hace bastante tiempo- es la clave de Web 2.0, Ajax y casi todo lo demás que vas a aprender en esta columa por lo próximos meses. Para darte una rápida vista, estos son solo algunos de los métodos y propiedades que vas a usar en este objeto:

open(): establecer una nueva petición a un servidor
send(): enviar una petición al servidor
abort(): Escapar de la petición actual
readystate: provee el estado correcto del HTML actual
responseText: El texto que el servidor devuelve al responder una petición.

No te preocupes si no las entendés todas (o algunas para el caso) vas a aprender sobre cada método y propiedad en próximos artículos. Lo que deberías sacar de esto es una buena idea de que hacer con XMLHttpRequest. Observa que cada uno de esos métodos y propiedades se relacionan con mandar una petición y tratar con la respuesta. De hecho, si mirás cada método y propiedad de XMLHttpRequest, estarán todas relacionadas a ese tan simple modelo petición/respuesta. Por eso claramente, no vas a aprender sobre un sorprendente objeto GUI nuevo o alguna clase de avance super secreto para crear interacción con el usuario; vas a trabajar con simples peticiones y simples respuestas. Puede ser que no suene exitante, pero el uso cuidadoso de este objeto puede cambiar totalmente tus aplicaciones.
La simplicicidad de lo nuevo
Primero, necesitás crear una nueva variable y asignarle una instancia del objeto XMLHttpRequest. Eso es bastante simple en JavaScript; solo usa la nueva palabra clave con el nombre del objeto, como ves en el linsting 1

Listing 1. Crear un nuevo objeto XMLHttpRequest
<script language="javascript" Type="text/javascript">
var request= new XMLHttpRequest();
</script>

No es tan difícil, ¿no?. Recuerda, JavaScript no requiere que ingreses algo en sus variables, por eso no necesitas nada como lo que ven en Listing 2 (que sería como deberías crear este objeto en Java)

Listing 2. Crear un nuevo objeto XMLHttpRequest
XMLHttpRequest request= new XMLHttpRequest();

Entonces creaste la variable en Javascript con var, dandole un nombre (como "request") y despues le asignaste una nueva instancia de XMLHttpRequest. En esete punto, ya estas listo para usar el objeto en sus funciones.
Manejo de error
En la vida real, las cosas puede ir mal y este código no provee ningún manejo de error. Una pequeña mejora es crear este objeto y tener una salida elegante si algo sale mal. Por ejemplo, muchos navegadores viejos (aunque no lo creas, la gente todavía sigue usando versiones viejas de Netscape Navigator) no soportan XMLHttpRequest y necesitás hacerles saber que algo anda mal. El listing 3 muestra como deberías crear este objeto para que si algo falla, tire una alerta de JavaScript.

Listing 3. Crear XMLHttpRequest con algunas habilidades de tratamiento de error
<script language="javascript" type="text/javascript">
var request = false;
try {
request = new XMLHttpRequest();
} catch (failed) {
request = false;
}
if (!request)
alert("Error al inicializar XMLHttpRequest!");
</script>

Asegurate de entender cada uno de estos pasos:

Crear una nueva variable llamada request y asignarle un valor falso (false). Vas a usar falso como condición que signifique que el objeto XMLHttpRequest no haya sido creado todavía.
Agregarlo en un bloque try/catch

tratar y crear el objeto XMLHttpRequest
Si eso falla (catch(failed)), asegurate que request todavía sea falso.

Control si request es falso (si las cosas salen bien no lo será)
Si hubo un problema (y request es falso), usa un alerta JavaScript para decirle al usuario que hubo un problema.

Es bastante simple; es mas largo de leer y escribir, que de entender para la mayoría de los desarrolladores JavaScript y Web. Ahora tenes una piesa de código a prueba de error que crea un objeto XMLHttpRequest y hasta te avisa si algo sale mal.
Lidiar con Microsoft
Todo esto se ve bastante bien... por lomenos hasta que pruebes tu código en Internet Explorer. Si lo haces, vas a obtener algo tan feo como en la figura 1:

figura 1: Internet Explorer reportando un error.

Claramente, algo no está funcionando. Internet Explorer es duramente un navegador desactualizado y alrededor del 70% del mundo lo usa. En otras palabras, no harías bien en el mundo Web si no soportaras Microsoft e Internet Explorer! Por eso, necesitas una mejora diferente para lidiar con navegadores Microsoft.
Resulta que Microsoft soporta Ajax, pero llaman a su versión de XMLHttpRequest algo diferente. De hecho lo llaman de diferentes formas. Si estás usando una version nueva de IE, necesitas usar un objeto llamado Msxml2.XMLHTTP; algunas versiones mas viejas usan Microsoft.XMLHTTP. Necesitas soportar esos dos tipos de objetos (sin perder el soporte que ya tenes para los navegadores no-Microsoft). Revisa el listing 4 que agrega soporte para Microsoft al código que ya habías visto.

Listing 4. Agregar soporte para los navegadores Microsoft
<script language="javascript" type="text/javascript">
var request = false;
try {
request = new XMLHttpRequest();
} catch (trymicrosoft){
try {
request=new ActiveXObject("Msxml2.XMLHTTP");
} catch(othermicrosoft {
try {
request= new ActivexObject("Microsoft.XMLHTTP");
} catch (failed) {
request = false;
}
}
}
if (!request)
alert("Error al inicializar XMLHttpRequest!");
</script>

Es fácil perderse en estos vericuetos, por eso los guio a traves de ellos un paso por vez:

Crear una nueva variable llamada request y asignarle un valor falso (false). Usar el valor falso como condición para indicarque el objeto XMLHttpRequest no ha sido creado todavía.
Agregar el bloque try/catch

Probar y crear un objeto XMLHttpRequest
Si falla (catch(trymicrosoft))
Probar y crear un objeto compatible con Microsoft usando las más nuevas versiones de Microsoft (Msxml2.XMLHTTP)
Si falla (catch(othermicrosoft)), probar y crear un objeto compatible con Microsoft usando la version mas vieja de Microsoft (Microsoft.XMLHTTP)
Si aún falla, asegurate de que request siga establecida en falso

Verifica si request es todavia falso (si las cosa están bien, no será)
Si hay un problema (y request es falso), usa un alerta de Javascript para avisarles a los usuarios que hay un problema.

Has esos cambios a tu código y prueba las cosas en IE otra vez; deberías ver el formularioque creaste (sin mensaje de error). En mi caso, resulto algo como en la figura 2.

Figura 2: Internet Explorer trabajando normalmente

Traducción del articulo de Ajax V

2006-03-03T17:32:00.000-03:00

Bueno, para seguir con esto, vamos por la Parte II del asunto:

Dominar AJAX, Parte 2: Hacer peticiones asincrónicas con Javascript y Ajax
Usar XMLHttpRequest para peticiones Web
Nivel: Intermedio
Brett McLaughlin (brett@oreilly.com), Autor y Editor, O´Reilly y Asociados.
17 Ene 2006

La mayoría de las aplicaciones Web usan un modelo pedido/respuesta que toma una página HTML entera desde el servidor. El resultado es un ida y vuelta que generalmente involucra presionar el botón, esperar al servido, presionar otro botón y esperar un poco más. Con Ajax y el objeto XMLHttpRequestpodés usar un modelo de pedido/respuestaque nunca deja a los usuarios esperando a que un servidor les responda. en este artículo, Brett McLaughlin te muestra como crear instancias XMLHttpRequesten una forma multi-navegador , construir y enviar peticiones y respuestas al servidor.

En el último artículo de esta serie (ver en recursos por links), fuiste introducido a las aplicaciones Ajax y viste algo de los conceptos básicos que manejan las aplicaciones Ajax. En el centro de esto había un monton de tecnología que problablemente ya conocias: JavaScript, HTML and XHTML, un poco de HTML dinámico y tambien un poco de DOM (Modelo de objeto de documentos). En este artículo voy a focalizar desde esa vista de 10.000 pies y focalizar en detalles especificos de Ajax.
En este artículo, vas a empezar con el mas fundamental y básico de todos los objetos relacionados con Ajax y de mejoras de programación: el objeto XMLHttpRequest. Este objeto es realmente el único hilo en común entre todas las aplicaciones Ajax y , como como debes esperar, vas a querer entenderlo a fondo para llevar tu programación al límite de lo posible. De hecho, vas a descubrir que aveces, para usar XMLHttpRequest apropiadamente, no vas a usar XMLHttpRequest explicitamente. De que se trata todo esto?
Web2.0 de un vistazo
Primero, toma este último pedaito de repaso antes de que te sumerjas en el código, asegurate de tener clara esta idea sobre la Web 2.0. Cuando escuchas el término Web 2.0, deberías preguntar primero ¿que es Web 1.0? Sin Embargo raramente vas a escuchar Web 1.0, esto se refiere a la web tradicional donde se tiene un modelo de petición y respuesta bastante diferente. Por ejemplo, ir a Amazon.com y presionar un botón o ingresar un término de búsqueda. Una petición es hecha el servidor y luego una respuesta vuelve a tu navegador. Esa respuesta tiene mucho más que solo una lista de libros y titulos, sin embargo; realmente es otra página HTLML completa. Como resultado, probablemente tengas algo de destelleos u oscilaciones mientras la pantalla de tu navegador es redibujada con esta nueva página HTML. De hecho podes ver claramente la petición y la respuesta, delineada por cada nueva página que ves.
La Web 2.0 prescinde de esta tan visible ida y vuelta (en un alto grado). Como ejemplo, visitar un sitio como Google maps o Flickr (los links de ambos sitios web 2.0 potenciados con Ajax están de Recursos). En Gogle Maps, por ejemplo, podés mover el mapa con el mouse, ampliar o reducir la vista con muy poco redibujamiento. Por supuesto, se hacen peticion y respuesta aquí, pero todas detras de escena. Como usuario, la experiencia es mucho mas agradable y se siente mucho como una aplicación de escritorio. Esta nueva sensacion y paradigma es lo que ves cuando alguien se refiere a Web 2.0. Lo que te tiene que preocupar entonces es como hacer posible estas nuevas interacciones. Obviamente, todavía tenes que hacer peticiones y respuestas de campo, pero es el redibujamiento de el HTML para toddas interacción de petición/respuesta la que da la percepción de una interface Web lenta y pesada. Por eso claramente necesitas un acercamiento que te permitahacer peticiones y recibir respuestas que incluyan la información que necesitás, más que una página HTML entera. El único momento que vas a querer lebantar una página HTML entera es cuando... bueno... cuanto quieras que el usuario vea una nueva página.
Pero la mayoría de las interacciones agregan detalles o cambian el texto del cuerpo, o sobreponer información en las páginas existentes. En todos esos casos, Ajax y Web 2.0 acercan la posibilidad de enviar y recibir información sin actualizar una página HTML entera. Y para cualquier usuario web frecuente. Esta habilidad va a hacer que tu aplicación se sienta más rápida, más dinámica, y los traerá de vuelta una y otra vez

Traducción de artículo sobre Ajax IV

2006-02-28T17:38:00.000-03:00

Pescar en el formulario Web
¿Entonces que queda? Realmente no mucho. Tenen un método JS que toma la información que el usuario pone en el formulario, lo manda al servidor, le da otro método JS para escuchar y manejar la respuesta y hasta establecer el valor de un campo cuando la respuesta vuelve. Todo lo que realmente queda es llamar ese primer evento JS y empezar nuevamente todo el proceso. Podés obviamente agregar un botón a tu formulario HTMLpero eso es un poco 2001, ¿no te parece? Toma ventaja de la tecnología JS como en Listing 7

Listing 7.Lanzar un proceso Ajax
<form>
<p>Ciudad: <input name="ciudad" id="ciudad" size="25" onchange="callServer();" type="text"></p>
<p>Estado: <input name="estado" id="estado" size="25" type="text"></p>
<p>Código Postal: <input name="codigoPostal" id="codigopostal" size="5" type="text"></p>
</form>

Si esto se siente como otra piesa más de código de rutina, entonces estas en lo correcto, eso es. Cuando un usuario pone un nuevo valor para cualquier campo ciudad o estado, se dispara el método callServer() y la dirversión Ajax empieza. Estas empezando a sentir que tenes más manejo de las cosas? bien; esa es la idea!
En conclución
En este punto, probablemente no estarás listo para ir y escribir tu primer aplicación Ajax, al menos que desees hacer algo de investigación real en la sección recursos. Sin embargo podes tener una idea basica de como esas plaiciones trabajan y un entendimiento básico del objeto XMLHttpRequest. en el artículo que viene, vas a aprender especialmente este objeto, como manejar la comunicación JS-Servidor, como trabajar con formularios HTML, y también empezar a indagar en DOM.
Por ahora, tomate algo de tiempo para pensar sobre cuan poderosas pueden se las aplicaciones Ajax. Imagina un formulario web que te responda no solamente cuando apretes un botón, sinó cuando ingreses texto en un campo, cuando elijas una opcion de un cuadro desplegable, hasta cuando pases el mouse por la pantalla.Esto es exactamente lo que significa asincronico; pensá en código JS ejecutando y no esperado, en el servidor para responder a sus peticiones. ¿en que clase de problemas poder caer? ¿en que áreas vás a tener mas cuidado? y ¿como el diseño de tus formularios va a cambiar para justificar estas mejoras en programación?
Si te tomas un tiempo para estos temas, vas a estar mejor ubicado que solo tenienco código para cortar y pegar, y tirarlo en una aplicación que realmente no entiendas. En el próximo artículo vas a poner esas ideas en práctica y te voy a dar los detalles del código que necesites para hacer realmente aplicaciones como este trabajo. Entonces, hasta ese momento, disfuta de las posibilidades de Ajax.

Para los recursos ver el artículo original.

Traducción de Artículo sobre Ajax III

2006-02-27T16:27:00.000-03:00

Una Palabra sobre seguridad
¿Qué pasa con la seguridad? Los Navegadores actualesle dan al usuario la habilidad de manejar sus niveles de seguridad, apagar la tecnología JavaScript, y desabilitar cualquier numero de opciones en su navegador. En esos casos, tu código no va a trabajar bajo ninguna cirscunstancia. Para esas situaciones, vas a tener que manejar los problemas con gracia, es por lo menos un artículo en si mismo, uno que voy a enfrentar mas tarde (Va a ser una serie larga, ¿no?, no te preocupes vas a dominar todo esto antes de que termines). Por ahora, estas escribiendo código robustos, pero no perfecto, que es genial para empezar a entender Ajax. Vas a volver sobre los detalles más finos.

Pedido/respuesta en un mundo Ajax
Entonces ahora ntendes Ajax y tenés una básica idea sobre el objeto XMLHttpRequest y como crearlo. Si has leido en detalle, ya te habrás dado cuenta que es la tecnología JavaScript la que se comunica con cualquier aplicación Web en el servidor, más que tu formulario HTML siendo aceptado directamente para esa aplicación.
¿Cuál es la parte que falta? Como usar realmente el XMLHttpRequest. Como es código crítico que vas a usar de alguna manera en toda aplicación Ajax que escribas, hace un paseo rápido por como luce un modelo básico de petición/respuesta con Ajax.
Hacer una Petición
Tenés tu nuevo objeto XMLHttpRequest brillante; vamos a dar una vuelta en él. Primero, necesitás un método JavaScript que tu web pueda llamar (como cuando un usuario ingrese texto o seleccione una opción de un menú). Despues, vas a seguir las mismos puntos básicos en casi todas tus aplicaciones Ajax:

Obtener toda la información que necesites del formulario web
Construir la URL para conectarlo
Abrir una conección con el Servidor
Establecer una función para que el servidor ejecute cuando este hecho.
Mandar la petición.

El Listing 5 es un ejemplo de un método Ajax que hace especificamente esas cosas, en ese orden.

Listing 5. Hacer una petición con Ajax

function callServer() {
// Toma la ciudad y el estado del formulario web
var ciudad = document.getElementById("ciudad").value;
var estado = document.getElementById("estado").value;
//Solamente continua si hay valores para ambos campos
if((ciudad==null) || (ciudad=="")) return;
if((estado==null) || (estado=="")) return;
//Construir la URL para conectarse
var url = "/scripts/getZipCode.php?ciudad="+escape(ciudad)+" />
//open a connection to the server
xmlHttp.open("GET", url, true);
//Establecer una función para que el servidor ejecute cuando esté hecho
xmlHttp.onreadystatechange = updatePage
//Mandar la petición
xmlHttp.send(null);
}

Mucho de esto se explica solo. La primera parte del código usa JS básico para extraer los valores de algunos campos del formulario. Despues el código establece un script PHP como el destino para conectarse. Ver como el URL del script es especificado y luego la ciudad y el estado (del formulario) son adosados a el usando simples parametros GET.
Despues, la conexión es abierta; este es el primer lugar donde ves el XMLHttpRequest en acción otra vez. El método de conexión es indicado (GET), tal como la URL para conectarse. El último parametro, cuando es establecido a Verdadero (true), solicita una conexión asincrónica (así haciéndolo Ajax). Si usaras falso (false), el código esperaría en el servidor cuando se hace la petición y no continuaría hasta una que respuesta sea recibida. Estableciéndolo a Verdadero (true) , tus usuarios pueden todavia usar el formulario (y hasta llamar otros métodos JS) mientras el servidor está procesando este pedido en el fondo.
La propiedad onreadystatechange del xmlHttp (recuerda, es tu instancia del objeto XMLHttpRequest) te permite decirle al servidor que hacer cuando termine de ejecutar (lo cual puede ser en cinco minutos o en cinco horas). Como el código no va a esperar al servidor, vas a necesitar hacerle saber al servidor que hacer para que puedas responderle. En este caso un método especifico, llamado updatePage(), va a ser accionado cuando el servidor termine de procesar tu pedido.
Finalmente, send() es llamdo con el valor null. Como ya agregaste la información para mandar al servidor (la ciudad y el estado) en el URL de petición, no necesitás mandar nada en la petición. Entonces esto dispara tu petición y el servidor puede hacer lo que le pediste que haga.
Si no tomas nada más fuera de esto, te das cuenta cuan fácil y simple es esto! Aparte de poner la naturaleza asincrónica del Ajax dentro de tu cabeza, es relativamente una tarea simple. Vas a apreciar cuanto te libera para concentrarte en aplicaciones e interfaces atractivas, más que en complicado código de petición/respuesta HTTP.
El código en el listing 5 es tan fácil como se ve. La información es texto simple y puede ser incluído como parte del URL. GET manda el pedido mejor que el más complicado POST. No hay XML con contenido de cabecera para agregar, sin información para mandar en el cuerpo de la petición, ésta es una utopía Ajax en otras palabras.
A no temer; Las cosas se van a poner mas complicadas a medida que esta serie avance. Vas a aprender como mandar peticiones POST, como establecer tipos de cabeceras y contenidos, como codificar XML en tus mensajes, comoagregar seguridad a tu petición... La lista es bastante larga! No te preocupes por las complicaciones por ahora; poné tu cabeza en las bases, y rápidamente vas a construir un completo arsenal de herramientas Ajax.
Manejar la respuesta Ahora necesitás tratar con la respuesta del servidor. Realmente solo necesitás saber dos cosas en este punto:

No hacer nada hasta que la propiedad xmlHttp.readyState sea igual a 4
El servidor va a colocar su respuesta en la propiedad xmlHttp.responseText.

La primera de ellas -estados correctos- avanza sobre el tema principal de el próximo artículo; vas a aprender sobre las etapas de una petición HTTP, más de lo que quisieras saber. Por ahora, si simplemente chequeas un determinado valor (4), las cosas van a andar (y vas a tener mas expectativas de ver el próximo artículo). El segundo ítem -usar la propiedad xmlHttp.responseText para obtener la respuesta del servidor- es fácil. El Listing 6 muestra un ejemplo de un método que el servidor puede llamar, basado en los valores enviados en el Listing 5.

Listing 6. Manejar la respuesta del servidor

function updatePage(){
if (xmlHttp.readyState == 4){
var respuesta = xmlHttp.responseText;
document.getElementById("CodigoPostal").value = response
}
}

Otra vez, este código no es tan difícil ni complicado. Espera al servidor para llamarlo en el estado correcto y usa el valor que el servidor le devuelve (en este caso, el código postal para la ciudad y estado que ingresó el usuario) para establecer el valor de otro campo del formulario. El resultado es que el campo CodigoPostal de pronto aparece con el código postal, pero el usuario nunca tuvo que apretar un botón. Esa es la sensación de aplicación de escritorio que hablabamos antes. Respuesta rápida, sensación dinámica y más todo con un poco de código Ajax.
Los lectores observadores notarán que el campo CodigoPostal es un campo de texto normal. Una vez que el servidor devuelve el código postal, los usuarios puede sobreescribir el valor. Es intencional por dos razones: para mantener simples las cosas en el ejemplo y para mostrarte que a veces querés habilitar a los usuarios a sobrescribir lo que el servidor dice. Mantengan ambas cosas en mente; son importantes el el buen diseño de interfaces de usuario.

Traducción del Artículo sobre Ajax II

2006-02-23T12:18:00.000-03:00

Completar con DOM
Por último pero no menos importante, está el DOM, el modelo de objetos de documento. Para alguno de ustedes, escuchar sobre DOM puede ser un poco intimidante, no es usado regularmente por los diseñadores de HTML y es todavía mas inusual para codificadores de JS a no ser que estén en tareas de programación de gran embergadura. Donde se encuentra mucho DOM en uso es en sólidos programas de Java y C/C++; de hecho, probablemente por esto es que, DOM adquirió un poco de su reputación de ser difícil o duro de aprender.
Afortunadamente, usar DOM en tecnología JS es fácil y mayormente intuitivo. En este punto, normalmente muestro como usar DOM o por lo menos doy algunos ejemplos de código, pero eso sería un engaño. Verás, podés entrar bastante rápido en Ajax sin tener que lidiar con DOM y ese es el camino que les voy a mostrar. Volveré al DOM en un futuro artículo, pero por ahora, solo tené en cuenta que está ahí. Cuando empieces a enviar XML ida y vuelta entre código JS y el servidor y realmente cambies el formulario HTML, vasa volver a indagar en DOM. Es fácil obtener algo de Ajax efectivo sin él, así que postergalo por ahora.
Obtener el objeto Petición
Con una descripción básica adquirida, estás listo para para ver algunos detalles. Como XMLHttpRequest es cetral para las aplicaciones Ajax, y probablemente nuevo para muchos de ustedes, voy a empezar ahí. Como viste en Listing 1 debería ser bastante fácil crear este objeto y usarlo, correcto? Espera un minuto.
Trabajar con navegadores Microsoft
El navegador de Microsoft, Internet Explorer, usa el programa de análisis MSXML para trabajar el XML (puedes encontrar mas sobre MSXML en Recursos) Entonces cuando escribas aplicaciones Ajax que necesiten trabajar en Internet Explorer, vas a necesitar crear el objeto de una manera particular.
Sin Embargo, no es tan fácil. MSXML realmente tiene dos versiones diferentes dando vueltas dependiendo de la versión de la tecnología JS instaslada en Internet Explorer, por eso tenés que escribir el código que maneje ambos casos. Mirá en Listing 3 el código que necesitás para crear un objeto XMLHttpRequest en Navegadores Microsoft.

Listing 3: Tomar y establecer valores de campo con código JS
var xmlHttp = false
try {
xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (e2) {
xmlHttp = false;
}
}

Todo esto no es exactamente lo que necesitamos, pero está bien. Vas a indagar en programación en JavaScript, manejo de Errores, compilación condicional y mas antes de que esta serie termine. Por ahora tenes que tener dos líneas básicas en tu cabeza:
xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
y
xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");

Aislado, este código trata de crear el objeto usando una versión de MSXML; si falla, lo crea usando la otra versión. Lindo, no? Si ninguno de esos anda, la variable xmlHttp se establece a falso, para decirle a tu código que algo no esta andando. Si ese es el caso, probablemente tengas un navegador no-Microsoft y necesitas usar un código diferente para hacer el trabajo.
Trabajando con Mozilla y navegadores No-Microsoft
Si Internet Explorer no es tu navegador elegido o escribís código para navegadores No-Microsoft, entonces necesitás código diferente. De hecho, es la simple línea de código que viste en el listing 1:
var xmlHttp = new XMLHttpRequest object;
Esta línea mucho mas simple crea un objeto XMLHttpRequest en Mozilla, Firefox, Safari, Opera y casi todos los otros navegadores No-Microsoft que soporten Ajax de cualquier manera o moda.
Ponerlos juntos
La clave para soportar todos los navegadores. ¿Quién quiere escribir una aplicación que trabaje solo en internet explorer o una que trabaje solo en navegadores No-Microsoft ? Peor todavía, ¿querés escribir tu aplicación dos veces? Por supuesto que no! Entonces combiná tu código para que soporte a ambos. El Listing 4 muestra el código que hace solo eso:

Listing 4: Crear un objeto XMLHttpRequest de la forma multi-navegador
/*Crear un nuevo objeto XMLHttpRequest para comunicarse con el servidor*/
var xmlHttp = false;
/*@cc_on @*/
/*@if (@_jscript_version 5)
try {
xmlHttp = new ActiveObject("Msxml2.XMLHTTP"):
} catch (e) {
try {
xmlHttp = new ActiveObject("Microsoft.XMLHTTP"):
} catch (e2) {
xmlHttp = false
}
}
@end @*/
if (!xmlHttp typeof XMLHttpRequest != 'undefined') {
xmlHttp = new XMLHttpRequest();
}

Por ahora, ingnorá los comentarios y etiquetas extrañas tal como @cc_on; son comandos de compliación especiales de JavaScript que vas a explorar en profundidad en mi próximo artículo, que va a estar focalizado especificamente en XMLHttpRequest. Este código puede dividirse en tres fases:

Crear la variable xmlHttp patas referir el objeto XMLHttpRequest que vas a crear
Tratar de crear los objetos en navegadores Microsoft:

tratar y crear el objeto usando el objeto Msxml2.XMLHTTP
Si eso falla, tratar y crear el objeto usando el objeto Microsoft.XMLHTTP

Si xmlHttp no está todavía establecido, crear el objeto en la manera no-Microsoft

Al final de este proceso, xmlHttp debe referenciar a un objeto XMLHttpRequest válido, sin importar que navegador utilicen los usuarios.

-----------

Bien, hoy fue un poco menos, mañana veremos que pasa..

Traducción de Artículo sobre Ajax

2006-02-22T15:58:00.000-03:00

Este artículo se encuentra originalmente en IBM y lo encontré vía kblog y es una traducción cuyo unicos objetivos son practicar mi inglés y aprender Ajax. Aclaro que solo es una traducción de alguien que apenas está estudiando. Se aceptan aportes, correcciones, críticas, etc.
Dominar Ajax, Parte 1: Introducción a Ajax
Entender Ajax, un acercamiento productivo a la construcciones de sitios web, y como trabajan.
Nivel: Introductorio
Brett McLaughlin (brett@oreilly.com, Autor y Editor, O´Reilly y Asociados.
06 dic 2006

Ajax, que consiste en HTML, JavaScript tecnology, DHTML y DOM, es un excepcional acercamiento que te ayuda a transformar interfases web pesadas en aplicaciones interactivas Ajax. El autor, un experto en Ajax, demuestra como esas tecnologías trabajan juntas -desde una breve descripción a una vista detallada- para hacer el desarrollo web extremadamente eficiente una facil realidad. Tambien revela los conceptos centrales de Ajax, incluido el XMLHttpRequest object.

Cinco años atras, si no sabías XML, eras el patito feo a quien nadie hablaba. Dieciocho meses atrás, Ruby tomo popularidad y los programadores que que no sabían que estaba pasando con Ruby no eran bienvenidos en el dispenser(1). Hoy, si queres estar en lo último de la tecnología, AJAX es donde.
Sin Embargo, Ajax es mucho mas que solo un capricho; es un poderoso adelanto para la construcción de sitios web y no es tan duro como aprender un nuevo lenguaje completo.
Antes, voy a profundisar en que es Ajax, aunque, vamos a gastar solo unos momentos en entender que hace ajax. Cuando escribes una aplicación hoy, tenés dos opciones básicas:

Aplicaciones de Escritorio

Aplicaciones Web

Ambas son familiares, las aplicaciones de escritorio generalmente vienen en CD (o a veces se bajan de un sitio web) y se instalan completamente en tu computadora. Se puede usar Internet para descargar actualizaciones, pero el codigo que ejecutan esas aplicaciones reside en tu escritori. Aplicaciones Web- y no hay sorpresas aquí- se ejecutan en un servidor web en algún lugar y accedés a la aplicación con tu navegador Web.
Más importante que donde se ejecuta el código para esas aplicaciones es, sin embargo, como las aplicaciones se comportan y como se interactúa con ellas. Las aplicaciones de escritoriogeneralmente son un poco mas rápidas (se ejecutan en tu computadora, no tenés que esperar a la conexión de internet), tienen interfaces de usuario grandiosas (generalmente interactuan con tu sistema operativo) y son increiblemente dinamicas. Podés clickea, apuntar, tipear, desplegar menus y submenus y navegar por ella casi sin esperas.
Por otro lado, las aplicaciones web generalmente son actualizadas al segundo y proveen servicios no podrías tener nunca en tu escritorio (pensemos en Amazon.com y ebay). Sin Embargo, con el poder de la Web vienen las esperas: espera a que el servidor responda, espera a que las pantalla se actualicen, espera de la peticiones para volver y generar una nueva pagina.
Obviamente esto es un poco una simplificación, pero tenés la idea básica. Como probablemente ya estarás sospechando, Ajax trata de disminuir el espacio entre la funcionalidad e interactividadde la aplicación de escritorio y de la siempre-actualizada aplicacion Web. Podés usar interfaces de usuario dinamicas y controles mas lujososcomo los que encontrás en las aplicaciones de escritorio, pero disponibles en uan aplicación Web.
entonces, que estas esperando? Empezá a mirar a Ajax y como transformar tu pesada interface Web a aplicaciones Ajax de rápidas respuestas.
Vieja tecnología, nuevos trucos
Cuando se entra a Ajax, La realidad es que involucra un monton de tecnologías, para estar mas allá de los fundamentos, necesitas insistir en varias tecnologías diferentes (Esto es la razón por la cual pase algunos artículos iniciales de esta serie describiendo cad auna de ellas). La buena noticia es que probablemente ya conoscas un parte decente sobre varias de estas tecnologías, mejor todvía, la mayorías de esas tecnologías individuales son faciles de aprender, ciertamente no tan difícil como un lenguaje de programación entero como Java or Ruby.
Acá están las tecnologías básicas implicadas en en las aplicaciones Ajax:

HTML se usa para construir formularios web e identificar campos para usar en el resto de la aplicación.
El código JavaScript es el código base ejecutado por las aplicaciones Ajax y ayuda a facilitar la comunicación con las aplicaciones servidor.
DHTML o HTML dinámico, ayuda a actualizar los formularios dinámicamente. Vas a usar div, span y otros elementos de HTML dinámico para comentar(2) tu HTML
DOM, Modelo de Objetos de Documento, va a ser usado (vía código Javascript) para trabajar con ambos: La estructura del HTML y en algunos casos el XML devuelto por el servidor.

Vamos a desglosarlos para tener una mejor idea de que hacen cada uno. Voy a indagar mas en cada uno de ellos en futuros artículos. Ahora focalicemos en familiarizarnos con esos componentes y tecnologías. Cuanto mas familiarizado estés con este código, más facil va a ser moverse desde conocimiento ocacional sobre estas tecnologías a dominarlas (y realmente mejorar(3) el desarrollo de tu aplicación web).
El objeto XMLHttpRequest
El primer objeto que vas a querer entender es probablemente el que te es más nuevo, se llama XMLHttpRequest. Es un objeto de JavaScript y se crea tan simple como se muestra en Listing 1

Listing 1: Crear un nuevo objeto XMLHttpRequest

<script languaje="javascript" type="text/javascript">
var xmlHttp=new XMLHttpRequest();
</script>

Voy a hablar mas sobre este objeto en el próximo artículo, pero por ahora tengan en cuenta que este es el objeto que maneja todas las comunicaciones con el servidor. Antes de seguir, para y piensa: es la tecnología javascript a travez del objeto XMLHttpRequest la que habla con el servidor. No es el flujo normal de las aplicaciones y es donde Ajax toma mucha de su magia.
En una aplicación web normal, los usuarios completan formularios y hacen click en el botón de Submit. Entonces el formulario completo es enviado al servidor, el servidor transfiere el procesamiento a un Script (generalmente PHP, o Java o puede ser un proceso CGI o algo similar) y cuando el escrip está hecho, devuelve un pagina completamente nueva. Esa página puede ser HTML con un nuevo formulario, con algo de información completada, o puede ser una confirmación o capás una página con algunas opciones selecionadas basadas en información ingresada en el formulario original. Por supuesto, mientras el script o programa en el servidor esta procesando y devolviendo el nuevo formulario, los usuarios tienen que esperar. Sus pantallas se limpiaran y luego se redibujaran con la información que vuelve del servidor. Aca es donde la interactividad entra en juego: los usuarios no obtienen respuesta instantanea y ciertamente no sienten que estén trabajando en una aplicación de escritorio.
Ajax esencialmente pone la tecnología JavaScript y el objeto XMLHttpRequest entre tu formulario Web y el servidor. Cuando los usuarios completan formularios, es información es enviada a algun código JavaScript y no directamente al servidor. En cambio el código Javascript toma la infomación del formulario y manda una petición al servidor. Mientras esto está pasando, el formulario en la pantalla del usuario no se mueve, refresca, centellea, desaparece o para. En otras palabras, el código JavaScript manda el código en secret, el usuario no se da cuenta que la petición ha sido hecha. Todavía mejor, la peticion es enviada asincronicamente, que significa que tu JavaScript (y el usuario) no esperan sin hacer nada a que el servidor responda. Entonces los usuarios pueden continuar ingresando información, moviendose en la pantalla, y usando la aplicación.
Luego, el servidor devuelve la información a tu código JavaScript (todavía esperando en el formulario Web) que decide que hacer con esa información. Puede actualizar campos de formularios en la marcha, dando ese sensacion de inmediatoa tu aplicación, los usuarios obtienen información sin que sus formularios hayan sido aceptados o refrescados. El código JavaScript puede demas tomar la información, realizar algunos cálculos y mandar otra petición, todo sin la intervensión del ususario! Este es el poder del XMLHttpRequest. Puede comunicarse de ida y vuelta con el servidor todo lo que quiera, sin que el usuario se entere de que eso está pasando. El resultado es un experiencia dinámica, de respuesta rápida, y altamente interactiva como la de una aplicación de escritorio, pero con todo el poder de internet detrás.
Agregar algo de JavaScript
Una vez que manejes XMLHttpRequest , el resto de tu código JS va a parecerte un poco aburrido. De hecho, vas a usar código JS solo para algunas tareas básicas:

Tomar la información del formulario: el código Js hace simple sacar la información fuera de tu formulario y lo mandarla al servidor.
Cambiar valores en el formulario: tambien es simple actualizar un formulario, desde los valores de los campos elegidos para reemplazar imagenes en la marcha.
Analizar HTML y XML: vas a usar código JS para manipular el DOM (ver la siguiente sección) y para trabajar con la estructura de tu formulario HTML y cualquier información XML que devuelva el servidor.

Para lso dos primeros items, vas a necesitar familiarizarte con el método getElementById() como se muestra en listing 2

Listing 1: Tomar y establecer valores de campo con código JS

//Tomar el valor del campo "telefono" y ponerlo en una variable llamada telefono
var telefono = document.getElementById("telefono").value;

// Establecer algunos valores en un formulario usando un arreglo llamado respuesta
document.getElemenById("orden").value= respuesta[0];
document.getElemenById("direccion").value= respuesta[1];

No hay nada particularmente destacable acá y eso es bueno! Debes empezar a darte cuenta que no hay nada tremendamente complicado sobre esto. Una vez que manejes XMLHttpRequest , mucho del resto de tu aplicación Ajax va a ser código JavaScript simple como el que se muestra en el listing 2, mesclado con un poco de HTML inteligente. Entonces, a veces hay un poco de trabajo de DOM... por eso vamos a mirar eso.

Mañana sigo... bye.

(1) water cooler gossip: conversación o chusmerío que se forma alrededor del dispenser de agua en las oficinas.
(2) to mark up: to write notes or instructions for changes on a piece of writing, music etc.
(3) blowing the doors off: expresion que no encontré traducción.

Pinien

2006-02-15T15:37:00.000-03:00

Tener dicho algo en Mapuche.
Tengo ganas de tener algo dicho. Unicamente con este poco original propósito empiezo este blog. Ni siquiera se si significa esto, pero me gustó y de eso se trata, de que me guste.
Ademas provengo de estas tierras que alguna vez fueron de ellos y es probable, aunque no lo sé, que algo de su sangre corra en mis venas. Es es mi más que humilde homenaje.