Archivo

Archive for the ‘AJAX’ Category

JavaScript Patterns by Stoyan Stefanov

noviembre 3, 2010 13 comentarios

JavaScript Patterns by Stoyan Stefanov

This book is really awesome, from the beginning to the end, the author shows useful tools to improve the javascript programming.

With more than 30 patterns the author goes from basic concepts, such as avoiding globals, using single var declarations, precaching length in loops, following coding conventions, running JSLint, etc., to advanced ones like variable hoisting, select algorithms at runtime, proxy objects, loading strategies, javascript optimization and a lot of more.

What I liked about the book was the way in which the author explains and illustrates the patterns and how well organized the book is written, this book helped me to understand in a better way some javascript techniques with several solutions to a common scenarios.

I recommend this book if you want to write better code, if you want to understand how the libraries are written or if you want to write your own javascript library. It helps a lot to understand the javascript core and the fundamentals and helps also to be more productive taking care of performance and maintenance of javascript code.

You can buy from O’Reilly

http://oreilly.com/catalog/9780596806767/

or from amazon

http://www.amazon.com/JavaScript-Patterns-Stoyan-Stefanov/dp/0596806752/

I review for the O'Reilly Blogger Review Program

Anuncios
Categorías:AJAX, javascript Etiquetas:

Aplicaciones Web Offline con el archivo manifest de HTML5 (Offline Application Cache)

octubre 6, 2010 7 comentarios

Existe una característica en HTML5  llamada Offline Application Cache que permite a los usuarios correr aplicaciones Web aun y cuando no estén conectados a Internet. Funciona de la siguiente manera:

Cuando un usuario visita una aplicación Web, el navegador descarga y guarda todos los archivos necesarios para desplegar la página (HTML, CSS, javascript, imágenes, etc).

La siguiente vez que el usuario visita la aplicación, el navegador reconoce la dirección y sirve los archivos del cache de la aplicación local, en lugar de obtenerlos por la red.

El principal componente de esta característica se llama archivo de manifiesto (manifest file), que es un archivo de texto que se guarda en el servidor Web. Este archivo se envía al dispositivo del usuario y su tipo mime es cache-manifest.

Este archivo contiene una lista de archivos que el dispositivo del usuario debe descargar y guardar para que funcione la aplicación.

Ejemplo.

Por ejemplo supongamos una página HTML que se usa de splash para correr una aplicación la estructura de archivos sería la siguiente:

index.html

_img/splash.png

_js/index.js

_css/index.css

app.manifest

Los pasos para utilizar esta característica (Offline Application Cache)

1. Crear un cache manifest.

El archivo app.manifest tendrá las referencias a todos los recursos que queremos guardar en el cache de la aplicación:

Contenido de app.manifest:

CACHE MANIFEST
#Cache para la aplicación que no tenga conexión de red
#V1
#Archivos HTML
index.html
#Archivos javascript
_js/index.js
#Archivos CSS
_css/index.css
#Imagenes
_img/splash.png

Las rutas son relativas al archivo (también se pueden usar rutas absolutas), las líneas que comienzan con # son comentarios.

2.  Referenciar el archivo cache.

Para que se tenga acceso offline y funcione la aplicación con los archivos específicos en el archivo se necesita ligarlo, agregando un atributo manifest a la etiqueta de html dentro del index.html.

<html manifest=”app.manifest”>

Se debe configurar el tipo mime correcto (text/cache-manifest) en el servidor Web, porque si no, el navegador no lo va a reconocer.

En apache, el archivo mime.types se encuentra en el fólder /conf/ al final del archivo se escribe:

#HTML5 applicacion cache_offline access

text/cache-manifest manifest

Si no se tiene acceso a esa carpeta entonces se crea un archivo .htaccess en el directorio Web con la siguiente línea:

AddType text/cache-manifest .manifest

Con esto la aplicación debe funcionar correctamente, la segunda  vez que un usuario visite la aplicación, los recursos listados en el archivo se descargaran localmente de su dispositivo. (Móvil o desktop).

Actualizando el archivo.

Cuando el usuario visita el sitio, el navegador compara los archivo manifest (local y remoto) y checa si son iguales, si el archivo remoto cambió, el navegador descarga todos los archivos listados en el.

La comparación del contenido de los archivos se realiza byte por byte (incluyendo comentarios y líneas vacías), el cambio de alguno de los archivos listados en el manifest es irrelevante para determinar si se hizo algún cambio o no.

Hay que tomar en cuenta que cuando se actualiza un archivo, la descarga de los nuevos archivos se hace en el fondo, después de que se cargó la web app. Esto significa que incluso después de descargar los nuevos archivos, el usuario seguirá trabajando con los archivos viejos. Los archivos nuevos que fueron descargados en el fondo, no serán visibles hasta que el usuario vuelva a lanzar la aplicación. (leer mas adelante la solución a esto).

También es posible forzar al navegador a cargar ciertos recursos de la red siempre, por medio de la instrucción NETWORK,  por ejemplo si quisiéramos que una imagen siempre sea solicitada del servidor web, dentro del archivo manifest se declara de la siguiente manera

NETWORK:
imagen.jpg

El problema de esto es que si la aplicación se corre cuando no hay conexión, la imagen se tratara de cargar desde el servidor, para solucionar esto se puede utilizar otra instrucción para especificar que si no existe conexión se cargue un archivo local, y si hay se cargue el archivo desde el servidor.

En lugar de la instrucción NETWORK se utilizaría FALLBACK de la siguiente manera:

FALLBACK
imagen.jpg imagenLocal.jpg

Cuando el usuario tenga conexión la aplicación solicitará al servidor imagen.jpg y cuando no tenga usará la imagen del cache (imagenLocal.jpg).
También se puede especificar una sola imagen para mostrar cuando la aplicación este sin conexión, en lugar de todas las imágenes que se muestran en la aplicación.

FALLBACK
_img/ _img/imagenLocal.jpg

Objeto applicationCache.

Como ya expliqué, cuando un usuario visita una página que tiene un archivo manifest, el navegador trata de comparar o actualizar el cache, lo hace comparando los archivos (local y del servidor). Si los archivos son diferentes, se descargan los recursos y se almacenan de nuevo.

Mientras esto pasa, varios eventos se disparan en un objeto llamado ApplicationCache, con este objeto por ejemplo podemos actualizar al usuario con los nuevos archivos descargados,  sin necesidad de volver a lanzar  la aplicación.

API.

cache = window.applicationCache

Regresa un objeto ApplicationCache del documento activo de la ventana.

cache.status

Regresa el código de estatus actual del objeto con las siguientes constantes:

0 : uncached

1 : idle

2 : checking

3 : downloading

4 : updateready

5 : obsolete

cache.update()

Invoca el proceso de descarga de cache, arroja una excepción  de tipo INVALID_STATE_ERR en caso de que no exista cache para actualizar.

cache.swapCache()

Cambia el cache mas reciente en caso de que exista uno, si no, arroja una excepción de tipo  INVALID_STATE_ERR

Ejemplo.

Para actualizar la aplicación con los archivos nuevos sin recargar la aplicación:

Window.applicationCache.addEventListener(‘updateready’, function(){
Window.applicationCache.swapCache();}, false);

Esta característica es muy importante para el futuro de las aplicaciones Web móviles, el limite en iphone al parecer es de 5mb, en los demás dispositivos (Android, blackBerry, Palm) aun no lo he encontrado.

Eventos de javascript

agosto 30, 2010 Deja un comentario

Mientras que antes los sitios web solo usaban javascript para desempeñar tareas simples, las aplicaciones Web de hoy en día usan una gran cantidad de código Javascript, para programar interfaces de usuario complejas, ejecutando muchas líneas de código cada vez que el usuario interactúa con la aplicación.

Conocer acerca de los eventos de javascript es de gran ayuda para un desarrollador Web que tiene como objetivo crear aplicaciones que respondan a las acciones que realice el usuario de manera eficiente y tan rápido como sea posible.

Cuando un usuario interactúa con el navegador, el sistema operativo recibe entradas desde varios dispositivos como el teclado o el mouse y es tarea del navegador procesar los eventos individuales que se van generando y decidir qué hacer con cada evento, por ejemplo desplegar un menú ó ejecutar javascript cuando el usuario da un clic a un elemento.

Sin eventos no hay aplicaciones que reaccionen a las necesidades del usuario, todos los navegadores proveen API’s sencillas para su manejo (aunque con diferentes implementaciones).

Existen 3 API´s para controlar eventos:
La original de Netscape que soportan todos los navegadores,  la cual es la que se agrega como atributo de un elemento (como el onclick)  y solo se le asigna una función.
La  de Microsoft la cual tiene un método llamado attachEvent.
La del W3C que es la que se usa el método addEventListener y agrega un parámetro extra el cual generalmente se especifica como falso (false).

El modelo de evento de los navegadores, permite que un evento se vaya “pasando” a través de elementos.

El evento empieza en el nodo donde es generado, si el nodo no tiene un manejador del evento, entonces se pasa a su ancestro y si el ancestro tampoco tiene manejador del evento, se pasa de nuevo al ancestro siguiente y así sucesivamente hasta el nodo raíz.

A esto se le conoce como “event bubbling” (IE) o “event capturing” (otros navegadores), y significa que más de un elemento puede responder a la misma acción. La diferencia de event bubbling y event capturing radica en el orden,  “event bubbling” va del nodo hacia sus ancestros y el orden de “event capturing” va del nodo raiz hacia el último hijo que contiene.
Por ejemplo supongamos que tenemos un div (div2) que tiene asignado un evento click, este div tiene como ancestro otro div (div1) que también tiene asignado un evento click, cuando se le da click al div2, se dispara el evento y ejecuta la función asignada, sin embargo el evento no se detiene ahí después de ejecutar la función, dispara también el evento click del div1.


<div id="div1" onclick="alert('Click en div uno');">
<div id="div2" onclick="alert(''Click en div dos');"></div>
</div>

“Event bubbling” y “Event capturing” se pueden evitar  con los métodos: event.cancelBubble = trueevent.stopPropagation (), event.preventDefault (), dependiendo del navegador, ó cancelando el evento por medio de la instrucción return false.

Vale la pena leer el artículo de @ppk con una explicación más detallada acerca de este concepto, en la siguiente liga: http://www.quirksmode.org/js/events_order.html

Cuando un navegador dispara un evento, genera un parámetro extra de tipo evento, el cual describe que es el evento y todo lo relacionado a él,  se llama “Event Object“, este objeto es el que mantiene el rastro de los eventos que ocurren en la página y guarda información relacionada al evento, por ejemplo las coordenadas de “x” y “y” de el mouse, el elemento en el cual ocurrió el evento o cual tecla se presionó. Generalmente el manejador de evento necesita esa información para saber cómo procesar el evento.

Se puede acceder a esta información directamente del Objeto Event, pero desafortunadamente la lista de propiedades varía de navegador en navegador, algunas propiedades son:

  • pageX, pageY ó screenX, screenY: la distancia en píxeles de X y Y de la esquina superior izquierda a el puntero del mouse.
  • wich : que se usa con el evento keypress para determinar el código numérico de la tecla que se presionó.
  • target ó srcElement:que es el elemento de donde se originó el evento por ejemplo el elemento al que se le dio click cuando se usa el evento click.

Para conocer más a detalle las propiedades del objeto Event desde diferentes perspectivas visitar las siguientes ligas:

De Mozilla : https://developer.mozilla.org/en/DOM/event
De MS: http://msdn.microsoft.com/en-us/library/ms535863%28VS.85%29.aspx
De Opera: http://dev.opera.com/articles/view/handling-events-with-javascript/
Eventos de IPhone http://developer.apple.com/safari/library/documentation/appleapplications/reference/safariwebcontent/handlingevents/handlingevents.html
API de eventos de Blackberry: http://docs.blackberry.com/en/developers/deliverables/18446/DOM_Events_Objects_1180979_11.jsp

En IE se puede acceder al objeto Event por medio del objeto explicito window.event, mientras que en los otros navegadores, se accede pasando un parámetro a la función del controlador del evento, por ejemplo:

document.onclick=function(e)
{
var e = window.event || e;
}

En el código anterior se pasa un parámetro (e) en la función, el cual será un objeto de tipo evento en la mayoría de los navegadores (pero no en IE),   el parámetro  se reemplaza con el mismo en caso de que exista ó  con el objeto global en caso de que no (IE). Después necesitaríamos saber cuál es el objeto que está llamando el evento, esta información se guarda en el evento pero de distinta manera target o srcElement.
Aun cuando se detecte el objeto Event entre los navegadores (con el script anterior), existen diferencias porque cada navegador soporta diferentes propiedades y métodos, existen varias tablas de compatibilidad que pueden ver en las siguientes direcciones:

http://www.javascriptkit.com/jsref/event.shtml
http://www.quirksmode.org/dom/events/index.html

Comúnmente varios elementos en una página requieren del mismo controlador de evento, por ejemplo en un catalogo de productos cada elemento requiere de un controlador para el evento onclick, para que despliegue información del producto y guarde un historial de los productos visitados cuando el usuario realice el click.

<div>
<a href="http://www.dominio.com/despliegaProducto/1"
onclick="return despliegaProducto(this, event, function()
{
guardaHistorial("prod_id",1); return false;
});"> Producto 1
</a>
</div>

Si tuviéramos 50 productos   tendríamos que repetir el mismo código en cada elemento lo que incrementaría algunos KB de basura transferida a los usuarios, la información que es distinta es la clave del producto y en caso de que tuviéramos diferentes plantillas para el despliegue del producto seria la liga.

Delegación de eventos (Event delegation), es el nombre que se le da comúnmente a la técnica de enlazar (bind) un solo controlador de evento a un elemento raiz que contiene todos los elementos que necesitan responder a ese evento, cuando el evento es disparado en un elemento hijo, este se va al elemento raíz donde es controlado.

Se agrega  un conjunto de controladores a un elemento que sea el ancestro de varios elementos, cuando se ejecute el evento en alguno de sus “hijos” el elemento raíz pregunta cuál de ellos  es el que disparo el evento y después ejecuta el código, después cancela el paso del evento a su ancestro por medio de los eventos para cancelar el event bubbling.

El controlador distingue cual elemento hijo es el que ejecuto el evento y recibe parámetros adicionales por medio de algún atributo en ese elemento, por ejemplo para aplicar la delegación de eventos en el ejemplo anterior:

<div
onclick=”return despliegaProducto(event);”>>
:
<a href="http://www.dominio.com/despliegaProducto/" id="1" >
Producto 25
</a>
:
</div>

El nuevo controlador de evento obtiene el id del producto, el cual, es previamente pasado como un parámetro del atributo id del elemento (el <a> al que se le dio click):

<script>
function despliegaProducto(evt)
{
evt = evt || window.event; //Obtenemos el objeto event
var elemento = e.target || e.srcElement; //Obtenemos el elemento que se le dio el click
var idProducto = elemento.id; // se obtiene el id del producto
...
se procesa para el despliegue del producto y se guarda el historial
...
return false; // se cancela la acción del href de la liga.
}
</script>

La poca cantidad de código adicional que se agrega para que funcione la delegación es insignificante, además, que puede guardarse en un archivo js que se guarde en el cache, y nó  en el documento principal, por lo cual no se tiene que descargar cada vez que el usuario visita la página.

Otro concepto importante acerca de los eventos son los contextos de ejecución, los navegadores tienen un manejo de eventos de un solo hilo, con un modelo de programación asíncrono, está dirigido a un elemento  específico y generan  la ejecución de una función que controle el evento.

Esta función se ejecutará en un contexto de ejecución, cuando se termine, empieza a ejecutarse el siguiente evento creando otro contexto de ejecución, cuando se carga una página se crea un contexto global de ejecución, cuando se ejecutan funciones se van creando contextos adicionales de ejecución y se crea además una pila de contextos de ejecución donde el ultimo contexto creado es el activo.

Cuando se enlazan (binding) y desenlazan (unbinding) controladores de eventos, se usan las formas nativas de los navegadores: attachEvent y detachEvent en Internet Explorer, addEventListener y removeEventListener para los demás.
Las dos técnicas funcionan de manera muy similar, por ejemplo el siguiente código agrega un manejador de evento genérico:

function agregaManejador(elemento, tipo, manejador)
{
if (elemento.addEventListener) // todos los navegadores excepto IE
{
elemento.addEventListener(tipo, manejador, false);
}
else //Internet Explorer
{
elemento.attachEvent(“on”+tipo, manejador); // se le agrega el prefijo on para IE
}
}// agrega manejador
function quitaManejador(elemento, tipo, manejador)
{
if (elemento.removeEventListener) //todos los navegadores excepto IE
{
elemento.removeEventListener(tipo, manejador, false);
}
else if (elemento.detachEvent)
{
elemento.detachEvent(“on”+tipo, manejador);
}
}//quita manejador

//elemento = document.getElementById(“Id_del_elemento”);
//agregaManejador(elemento,”click”, funciondeClick);

El código anterior revisa si existe soporte para los eventos addEventListener () y removeEventListener (), los cuales son soportados por todos los navegadores excepto IE, si estos métodos no existen en el objeto, entonces se asume que el navegador es IE y se utilizan los métodos específicos para IE (attachEvent () y detachEvent ()).

El código funciona bien pero se puede optimizar, cada vez que se ejecutan las funciones agregaManejador () y quitaManejador () se realiza la misma comprobación para ver si un determinado método esta presente, entonces estas comprobaciones se repiten cada vez que se ejecutan las funciones. Tomando en cuenta que si addEventListener () estuvo presente en la primer ejecución, entonces estará presente en las consecuentes llamadas.
Repetir el mismo trabajo cada vez que se llama a una función afecta al rendimiento de las aplicaciones.

Una manera para eliminar el  trabajo repetitivo en funciones es por medio de un concepto que se llama “lazy loading“, que significa que no se hace trabajo hasta que la información es necesaria, en este ejemplo no hay necesidad para determinar la manera para crear controladores de evento hasta que alguien realiza una llamada a la función, la versión de “lazy loading” para la función anterior es:

function agregaManejador(elemento, tipo, manejador)
{
if (elemento.addEventListener) // todos los navegadores excepto IE
{
agregaManejador = function (elemento, tipo, manejador)
{
elemento.addEventListener(tipo, manejador, false);
}
}
else //Internet Explorer
{
agregaManejador = function (elemento, tipo, manejador)
{
elemento.attachEvent(“on”+tipo, manejador); // se le agrega el prefijo on para IE

}
}
agregaManejador(elemento, tipo, manejador);
}

function quitaManejador(elemento, tipo, manejador)
{
if (elemento.removeEventListener) //todos los navegadores excepto IE
{
quitaManejador = function (elemento, tipo, manejador)
{
elemento.removeEventListener(tipo, manejador, false);
}
}
else if (elemento.detachEvent)
{
quitaManejador = function (elemento, tipo, manejador)
{
elemento.detachEvent(“on”+tipo, manejador);
}
}
quitaManejador(elemento, tipo, manejador)
}

La primera vez que cualquiera de los dos métodos es ejecutado, se hace una revisión para determinar la manera correcta de hacer el trabajo, luego la función original es reescrita como una nueva función que contiene solo la manera correcta y el último paso en la primer llamada de la función es ejecutar de nuevo la función con los argumentos originales, cada llamada posterior a las funciones evitan la detección porque el código de detección fue sobrescrito por una nueva función.

La primer llamada a las funciones será siempre la que dure mas tiempo porque tiene que ejecutar el código de detección y después hacer la llamada a la nueva función para completar la tarea, las llamadas posteriores a la misma función son mas rápidas porque no tienen la lógica de ejecución.

Lazy loading” se utiliza cuando la función no se ejecuta inmediatamente en la página.

La segunda alternativa para mejorar el rendimiento de la función es por medio del patrón “Conditional Advance Loading” (carga condicional anticipada), que realiza la detección por anticipado o sea mientras se esta cargando el script, en lugar de esperar a que se llame la función, la detección se sigue haciendo solo una vez pero se hace anticipadamente:

var agregaManejador = document.body.addEventListener ?

function (elemento, tipo, manejador)
{
elemento.addEventListener(tipo, manejador, false);
} :
function (elemento, tipo, manejador)
{
elemento.attachEvent(“on”+tipo, manejador);
};

var quitaManejador = document.body.removeEventListener ?
function (elemento, tipo, manejador)
{
elemento.removeEventListener(tipo, manejador, false);
} :
function (elemento, tipo, manejador)
{
elemento.detachEvent(“on”+tipo, manejador);
};

En el código anterior se revisa si addEventListener () y removeEventListener () están presentes y usa la información para asignar la función mas apropiada, el resultado es que todas las llamadas a las funciones serán igualmente rápidas porque la detección se hace desde antes de la llamada.

Este patrón asegura que todas las llamadas a la función tomen la misma cantidad de tiempo, y se debe de usar cuando una función va a ser llamada inmediatamente y muy frecuente a través del tiempo de vida de la página.

Debemos ser cuidadosos en probar las aplicaciones en los diferentes navegadores, hay situaciones en que los eventos se comportan muy diferentes aún y cuando realicemos las detecciones del navegador.

A continuación listo los eventos que incluyen ya los navegadores mas modernos.

Eventos de mouse:

onClick ondragleave onmousemove onscroll
ondblClick ondragover onmouseout
ondrag ondragstart onmouseover
ondragend ondrop onmouseup
ondragenter onmousedown onmousewheel


Eventos de la ventana

onafterprint onfocus ononline onresize
onbeforeprint onhaschange onpagehide onstorage
onbeforeonload onload onpageshow onundo
onblur onmessage onpopstate onunload
onerror onoffline onredo


Eventos del teclado

onkeydown onkeypress onkeyup


Eventos de media

onabort onended onloadstart onwaiting
oncanplay onreadystatechange onpause onratechange
oncanplaythrough onvolumechange onplay onerror
ondurationchange onloadesdata onplaying onseeked
onemptied onloadedmetadata onprogress onseeking
onstalled onsuspend ontimeupdate


Fuentes:

Eventos del dom http://en.wikipedia.org/wiki/DOM_events
Podcast Javascript Events: http://www.yuiblog.com/blog/2009/04/27/video-ppk-jsevents/
Eventos: http://www.javascriptkit.com/jsref/event.shtml
Manual de ecmascript: http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf
Libro: Even Faster Web Sites Capítulo 7.
Libro: JavaScript The Good Parts Capítulo 4
Libro: High Performance JavaScript Capítulo 8
Libro: JavaScript the Missing Manual Capítulo Capitulo 6.

Document Object Model

febrero 9, 2007 Deja un comentario

Antes de que existiera el XML, estaba el Document Object Model o DOM, que permitia al desarrollador hacer referencia, obtener y cambiar elementos en una estructura de documento.

Un documento DOM es una coleccion de nodos, o piezas de informacion organizada de manera jerarquica. Esta organizacion permite al desarrollador navegar alrededor del arbol (como esta basado en una estructura jerarquica de informacion se dice que el DOM es basado en arbol tree-based) buscando por informacion especifica. El DOM es una manera de describir esos nodos, sus metodos y propiedades así como las relaciones que hay entre ellos.

En adicion al enfoque de una descripcion conceptual de datos XML, el DOM es una serie de recomendaciones propuestas por el world wide web consortium W3C, comenzo como una manera para los Navgadores Web puedan identificar y manipular elementos en una pagina.

Trabajar con el DOM involucra varias tecnologias que se complementan entre ellas (XPATH, XSLT, JavaScript).

El API (Application Programming Interface ) del dom contiene interfaces que representan todos los diferentes tipos de informacion que pueden encontrarse en un documento XML, tales como elementos y texto, tambien incluye los metodos y las propiedades necesarios para trabajar con estos objetos (clonar, borrar, insertar nodos).

El primer objeto para manejar los nodos del dom fue un ActiveX (Microsoft.XMLDOM) incorporado en la versión 5.0 del IE
Como existen varias versiones del MSXML.DOM al momento de utilizarlo es necesario hacer un script para detectar la versión mas actualizada y mantener el rendimiento mas alto de nuestras aplicaciones.
Nicholas C. Zakas desarrollo una libreria para manejar la compatibilidad llamada zXMLDOM la función que el desarrollo para detectar las versiónes va como la siguiente

function crearDocumento()
{
var versiones_Arr = [ “MSXML2.DOMDocument.5.0”,
“MSXML2.DOMDocument.4.0”, “MSXML2.DOMDocument.3.0”,
“MSXML2.DOMDocument”, “Microsoft.XmlDom”
];
for (var i = 0; i < versiones_Arr.length; i++)
try {
var oXmlDom = new ActiveXObject(versiones_Arr[i]);
return oXmlDom;
}catch (er)
{
//
}
throw new Error(“MSXML no esta instalado.” );
}

Esta función guarda las versiones del objeto MSXML DOM en un arreglo comenzando de la versión mas actual, despues recorre el arreglo e intenta crear el objeto, si el objeto se puede crear entonces se regresa el objeto, si no, el error es atrapado y continua con el siguiente elemento del arreglo, si ningún objeto se puede crear significa que el MSXML no esta instalado genera un error de que el objeto no esta instalado.
Implementación.

var oXMLDom = createDocument();

Por otra parte los desarrolladores de Mozilla Firefox desarrollaron su propia versión del objeto XMLDOM con la diferencia que se enfocaron a una forma mas estandar, desarrollando el objeto como una implementación de JavaScript, con esto se aseguran que cualquier versión de navegador basado en Gecko soporte el objeto.

Para crear un objeto XMLDOM se utiliza el método createDocument() de document.implementation

Este método acepta 3 argumentos
– Una cadena especificando el URI del documento a usar.
– El nombre del nodo raiz del documento
– Tipo de documento (doctype)

ejemplos de implementación:

Documento vacio
var oXMLDom = document.implementation.createDocument(“”,””,null);
Documento con un elemento
var oXMLDom = document.implementation.createDocument(“”,”raiz”,null);
Documento con un nameSpace definido
var oXMLDom = document.implementation.createDocument(“http://sitio.com&#8221;,”raiz”,null);

Los métodos, propiedades y eventos del MSXML Dom se pueden consultar en las siguientes paginas.
Dom
MSDN

Aunque son muy parecidos, entre los dos objetos XMLDOM existen diferencias de métodos, propiedades y eventos; para desarrollar una aplicación Ajax necesitamos implementar codigo que trabaje para los diferentes navegadores o podemos bajar alguna libreria con la programación realizada como la libreria anteriormente mencionada.

Categorías:AJAX

AJAX como plataforma de desarrollo

enero 15, 2007 Deja un comentario

Una de las principales discusiones acerca de adoptar AJAX como herramienta de desarrollo va orientada a las peticiones que se realizan hacia el servidor.

AJAX permite comunicarse con el servidor por medio de peticiones mas ligeras y especificas, con AJAX no hay necesidad de cargar una pagina entera solo para actualizar los valores de una determinada sección ya que el cliente es libre de comunicarse con el servidor y obtener información sobre demanda, la ventaja de esto es que los clientes experimentan una mejora de navegación en los sitios o aplicaciones ya que al no tener que cargar todo el contenido nuevamente, las respuestas hacia los usuarios son más rápidas, la desventaja es que debido al incremento de peticiones hacia el servidor se aumenta el desempeño del servidor de aplicación, obviamente este amento depende del funcionamiento de la aplicación.

  Como desarrolladores tenemos que utilizar técnicas de cache del lado del cliente para mitigar un poco la demanda de las peticiones y buscar un equilibrio razonable en el tamaño de las peticiones hacia el servidor.

  En aplicaciones robustas como un Portal, el uso de AJAX puede ser beneficioso ya que decrementa el cargado e incrementa la usabilidad para el usuario.

  Como ya comente anteriormente, mientras que el número total de peticiones usualmente aumenta en las aplicaciones Web con AJAX, el tamaño de las peticiones y respuestas son usualmente más pequeñas, ya que son orientadas a la funcionalidad que ha sido solicitada. En la mayoría de las aplicaciones Web, el número de usuarios simultáneos puede exceder al número de conexiones al servidor, esto es porque las conexiones pueden cerrarse durante las pausas frecuentes en la comunicación donde el usuario lee un contenido o completa una forma.

  Para los desarrolladores es un reto tratar con numerosas conexiones, si existen miles de usuarios, se necesitan miles de conexiones, debemos evaluar el sistema completo que va desde el sistema operativo hasta la implementación del hardware, y dentro de la construcción de la aplicación WEB tener cuidado con el uso de conexiones http.

  El perfil de tráfico típico de muchas aplicaciones Web es el de conexiones HTTP persistentes (hilos por conexión), la mayoría de estos hilos se quedan colgados mientras los usuarios leen las páginas.

  Con AJAX se puede implementar una técnica de hilos por petición y manejar un solo objeto de conexión que administre todas las peticiones hacia el servidor y que solo puedan ser permitidas peticiones cuando han sido procesadas las anteriores o cuando ocurra un evento, cuando llega una nueva petición se coloca en una cola de espera así cuando la conexión esta colgada o termina la petición, puede mandar pedir una nueva petición (hilo) de la cola de espera.

Una aplicación de AJAX colgada tendrá una petición esperando en el servidor, la cual puede ser usada para mandar una respuesta a el cliente en el instante que un evento asíncrono ocurra, es una buena técnica pero rompe con el modelo de hilo por petición porque cada cliente mantendrá una petición esperando del lado del servidor, además el servidor de nuevo necesita tener uno o mas hilos para cada cliente y se vuelve al problema de escalamiento de miles de usuarios simultáneos.

En el desarrollo de las aplicaciones con AJAX es necesario considerar las diferencias de código que existen entre los diferentes navegadores, para no limitar el uso de la aplicación a un solo navegador  podemos crear nuestras propias funciones que usen el codigo correcto dependiendo del navegador ó usar alguna libreria o framework que este disponible en la red, como por ejemlo Yahoo UI library DojoMochikit,   Echo

En lo referente a la detección de errores de los scripts podemos usar herramientas como  Firebug (mozilla),   Web Developer (mozilla),  Dom Inspector (mozilla),  IE Debugger ,  JSlint

  En cuanto a la prueba de rendimiento de la aplicación y evaluar peticiones al servidor podemos usar herramientas como  Fidller ó   Ethereal

Categorías:AJAX

AJAX. (Asynchronous JavaScript and XML)

noviembre 10, 2006 5 comentarios

Ajax es la definición de un conjunto de tecnologías (Java Script, DOM, XML, CSS, XMLHttp) que combinadas con la transmisión de pequeños paquetes de información en forma de peticiones (request) y respuestas (response) ofrece a los usuarios mayor usabilidad en el uso de aplicaciones por HTTP.

Con el uso de estas tecnologías los desarrolladores comenzaron a experimentar varias maneras para interactuar con los usuarios sin necesidad de hacer peticiones al servidor, esto ayudaba a procesar ciertas operaciones por medio del navegador sin tener que llegar al servidor. Era importante cuando los usuarios estaban conectados por un MODEM de 28.8 Kbps. y cada petición era tiempo de espera.

Desplegar una pagina web que pudiera ser dividida en varios documentos fue lo que se logró con la aparición de los FRAMES en el HTML 4.0.

La combinación de javaScript con los FRAMES fue el primer paso de la evolución de AJAX. Cómo un FRAME representaba una petición diferente a el servidor, la habilidad de controlar el FRAME y sus contenidos con JavaScript abrió la puerta hacia posibilidades excitantes. Una técnica utilizada es la de esconder un FRAME en la página web estableciendo las propiedades de ancho y alto en 0 pixeles. Con el único propósito de hacer las peticiones al servidor.

<frameset rows="*,0" frameborder="no" border="0" framespacing="0">    <frame src="pag1.html" mce_src="pag1.html" name="FActivo" id="FActivo">    <frame src="about:Blank" mce_src="about:Blank" name="FEscondido" scrolling="No"            noresize="noresize" id="FEscondido" / >

</frameset><noframes>

Declaración HTML para la técnica de frame escondido.

El FRAME escondido tiene una Forma HTML con campos específicos que son llenados dinámicamente con JAVASCRIPT y enviados de regreso al Servidor. Cuando el FRAME se recarga, llama a otra función javascript para notificar que los datos ya han regresado.  Esta técnica represento el primer modelo asíncrono para aplicaciones WEB.

DHTML permitió a los desarrolladores cambiar cualquier parte de la página cargada, con JavaScript. Combinando DHTML con la técnica del FRAME escondido se logra cambiar cualquier aspecto de una página sin hacer peticiones al servidor, este fue el siguiente paso en la evolución de AJAX.

Document Object Model (DOM) también es un actor importante en la evolución de AJAX, ya que provee una estructura completa para una página y permite modificaciones DHTML a la página. Ya con el DOM completamente implementado en Explorer 5 y Netscape 6, se tuvo la oportunidad de crear iframes dinámicamente, lo que significa que con una función JavaScript se podía crear un iframe, hacer una petición al servidor y obtener una respuesta todo sin haber incluido el código HTML. Esta fue la siguiente técnica usada en la evolución de Ajax.

Una de las extensiones de Microsoft a JavaScript permitía la creación de controles ActiveX. Cuando Microsoft empezó a soportar XML a través de una librería llamada MSXML, el objeto XMLHttp fue incluido. XMLHttp era mas que un manejador de XML, era mas bien una petición http que podía ser controlada por javascript. Los desarrolladores tuvieron acceso a los códigos de estado y cabeceras, que regresa el servidor.

Del otro lado los desarrolladores del proyecto Mozilla comenzaron a hacer su propio objeto replicando los principales métodos y propiedades de XMLHttp, llamado objectXMLHttpRequest.

Ajax es un conjunto de herramientas para la transmición de pequeños bloques de información hacia y del servidor en orden de dar al usuario mayor respuesta posible en su interacción con el web.

En lugar de segir el modelo tradicional de una aplicación web en donde el navegador es responsable de iniciar las peticiones al servidor y procesar las peticiones de regreso, AJAX provee una capa intermedia la cual Garrett (creador del término AJAX) llama Ajax Engine.

El motor de Ajax (Ajax Engine), solo es un objeto o una función javascript que es llamada cuando una petición es requerida haciea el servidor, a diferencia del modelo tradicional en donde un link manda llamar a un recurso (como una pagina web) cada liga manda llamar a la función javascript (Ajax Engine) la cual administra y ejecuta la peticion. Las peticiones se realizan de manera asincrona lo que significa que la ejecución del codigo principal no espera por una respuesta para continuar.

Siguiendo estos principios en el desarrollo de aplicaciones web se logra el principal objetivo de Ajax que es la Usabilidad.

Categorías:AJAX
A %d blogueros les gusta esto: