Hace varias semanas publiqué el
Manifiesto Single Page Interface promoviendo un "nuevo" mundo de sitios web basados en una sola página simulando páginas cuando fuera necesario. Ahora es el turno de acercar a todo el mundo esta "nueva" forma de construir sitios web a través de un tutorial basado en el framework
ItsNat.
El enfoque Single Page Interface no es nuevo, ha sido usado desde los inicios de la tecnología DOM, AJAX ha conseguido popularizar de forma masiva la técnica SPI gracias a algunos frameworks web, céntricos en el cliente o en el servidor, tal que hoy día la mayor parte de la innovación del mundo web tiene lugar en el mundo SPI.
A pesar de que el SPI es muy popular (y cada vez más) en
aplicaciones web puras, es casi totalmente ignorada en
sitios web. Los sitios web están formados por (muchas) páginas porque suelen tener fuertes requisitos tal y como la compatibilidad con los buscadores (también llamada Search Engine Optimization o SEO), poder guardar páginas como favoritos, soporte de los botones de Adelante/Detrás y algunos servicios basados en páginas como los contadores de visitas, visionado de anuncios etc.
El Manifiesto Single Page Interface mostró como podemos proporcionar esas características a aplicaciones SPI. El aspecto más problemático es la compatibilidad SEO, es decir que el contenido de nuestro sitio web SPI pueda ser recorrido por los robots de los buscadores; este requisito implica que nuestro sitio web debe ser basado en páginas para los buscadores y al mismo tiempo SPI para los usuarios normales (con JavaScript activado).
ItsNat es un framework céntrico en el servidor preparado para crear esta clase de
sitios web SPI. Resumiendo muy brevemente el enfoque de ItsNat es muy sencillo, en el servidor se mantiene un árbol DOM con el mismo estado que en el cliente, las modificaciones en el DOM servidor (usando Java W3C DOM) se actualizan automáticamente en el cliente y los eventos del cliente son enviados al servidor como Eventos Java W3C DOM Events cuando hay algún event listener registrado en el servidor. El sistema de templates está basado en archivos HTML puro, estos
templates pueden ser de
páginas o de
fragmentos.
Los templates de fragmentos son archivos HTML normales en los cuales el contenido del <body> es el que será usado (opcionalmente también el del <head>), son cargados como DOM cuando se necesitan desde código del programador y pueden ser insertados en cualquier momento usando la API DOM en el árbol DOM de la página de nuestra web SPI. ItsNat automáticamente inserta este nuevo código en el cliente usando innerHTML cuando es posible; cuando la propiedad innerHTML es definida cualquier navegador procesa este nuevo HTML con el parser nativo del navegador, mucho más rápido que en JavaScript usando DOM, por lo que el rendimiento es siempre mejor que cuando se parsea la página completa en tiempo de carga (incluso en el caso de cambio completo de la página a través de innerHTML) debido a que el parseado y construcción de un objeto DOM Document es siempre significativamente más costoso que cualquier fragmento.
Prácticamente cualquier sitio web suele repetir el mismo patrón visual, existe una cabecera y un pie de página que son compartidas entre todas las páginas con pequeñas modificaciones y en caso más simple hay una zona o área de contenido que es la que cambia en cada página. En desarrollo basado en páginas esto implica que todos los templates repiten cabecera y pie de página normalmente a través de algún tipo de directiva “include” parametrizada.
En ItsNat y SPI, la cabecera y el pie se diseñan una vez en el template “estructural” de la página y el equivalente a cada página de una aplicación clásica sería ahora un template fragmento incluyendo únicamente el markup que va a ser incluido en el area de contenidos. Cabeceras y pies pueden ser cambiados de acuerdo con los cambios de estado usando DOM APIs o bien si es necesario con otros template fragments cuando se necesario.
Hasta ahora hemos visto como ItsNat funciona en SPI y cómo convertir un sitio web a SPI, sin embargo no hay una sola palabra sobre el compromiso SEO, puesto que el código JavaScript es ignorado por los robots de los buscadores incluyendo el código JavScript enviado por ItsNat para sincronizar automáticamente la página cliente.
La solución obvia sería desarrollar dos sitios web, uno para los buscadores basado en páginas sin JavaScript y otro, el SPI, para los usuarios normales con JavaScript activados. Sin embargo esto NO es necesario en ItsNat.
¿Cómo puede un sitio web ser basado en páginas y SPI al mismo tiempo?
ItsNat tiene una característica clave en todo esto que es el modo “fast-load”.
Si el modo fast-load está desactivado la página inicial enviada al cliente como markup es el template de la página, las operaciones DOM hechas en tiempo de carga en el servidor por parte de código del programador, son enviadas como JavaScript al cliente. Este modo no es compatible SEO porque el template de la página, el patrón estructural de nuestro sitio web, no contiene el markup requerido del área de contenidos pues este contenido es insertado desde templates fragmento dependiendo del estado inicial (la página inicial en sentido clásico) que va a ser cargado, por tanto dicho contenido es cargado a través de llamadas a la API DOM y por tanto enviado como JavaScript e ignorado por los robots de los buscadores.
Sin embargo en el modo fast-load (el modo por defecto) el árbol DOM es serializado como markup
después de que el código del programador en el servidor sea ejecutado, como dicho código incluye en el árbol DOM de la página el markup del estado inicial de la página solicitado, dicho markup es también enviado al cliente como markup y por tanto los robots ven dicho contenido en formato HTML.
En resumen, el mismo código que cambia el árbol DOM en cualquier momento generando el JavaScript necesario sirve también, automáticamente, para construir la página inicial como HTML que es enviada al cliente.
El tutorial muestra todas estas ideas con un ejemplo concreto pero a la vez genérico incluyendo el código fuente, mostrando además cómo abordar el caso de sub-estados de un estado fundamental pero que a su vez es también un estado fundamental así como un ejemplo de estado secundario es decir que no necesita ser procesable (conscientemente) por los buscadores.
Otros problemas abordados son el problema de los favoritos (bookmarks) que se afronta con links duales, el Adelante/Atrás se detecta y se simula a través de la detección de cambios en el URL usando timers, y el contador de visitas de páginas se convierte ahora en un contador de visitas a estados fundamentales a través de un iframe.
Enlaces:
TutorialCódigo fuente y binariosDemo online
lunes, abril 5, 2010 at 1:26PM