Creación: 12-06-2010
Índice de contenidos
1. Introducción
2. La pregunta (by Carlos Arévalo)
3. La respuesta
3.1. Frames HTML
3.2. SPI
3.3. Mi opinión
4. Sobre el autor
1. Introducción
Bueno, lo primero decir que esto no es realmente un tutorial, o por lo menos no uno como los que suelo escribir. Este artículo surge de una pregunta que nos hizo uno de vosotros, una pregunta que nos ha parecido interesante como para dedicarle un pequeño artículo. Por eso lo he querido llamar IAQ (Interesting Asked Questions), o como diríamos por aquí, simplemente “Preguntas Interesantes”. Quién sabe si este articulo puede ser el primero de una nueva sección, a modo de las conocidas FAQ 😉
2. La pregunta (by Carlos Arévalo)
Hola, quería hacerte una consulta. Actualmente estoy realizando un proyecto en la universidad donde estudio y estoy utilizando Visual JSF con NetBeans 6.7.1, pero tengo un problema, el hecho es que no he podido crear una pagina maestra donde 3 elementos son fijos: el banner menú horizontal, y el menú lateral a la izquierda, y la única parte que cambia es donde he ubicado todos los formularios. El problema es que no quiero que toda la pagina se me este actualizando o recargando cada vez que realizo una acción, como por ejemplo hacer un filtro (este ya lo solucione con AJAX aunque a veces me da problemas), también cuando quiero pasar de un formulario a otro o guardo, quiero que la pagina no se recargue (o se actualice) toda.
Antes trabaja en Visual estudio 2008, y usaba master page, no se si aquí hay una forma de hacer algo que se le parezca.
3. La respuesta
Lo que le preocupa a nuestro amigo es que, efectivamente, en una aplicación suele haber muchas partes de la interfaz que no cambian, o que cambian muy rara vez. Si esto lo trasladamos a una aplicación web, donde lo que tenemos son páginas HTML, lo que puede suceder es que tengamos muchas páginas donde muchos elementos (cabecera, pie, menú de la izquierda, …) son siempre iguales. Esto podría causar que tuviéramos un trasiego innecesario de información entre el servidor y el navegador, ya que constantemente al pasar de una pantalla/página a otra estaríamos mandando siempre esos mismos elementos.
Para solucionar este problema, a lo largo del tiempo se han ido utilizando diferentes técnicas.
3.1. Frames HTML
El hecho de hacer que ciertas partes de la página no se recarguen constantemente y no tener que pedir la página entera, antes se hacia mucho con el uso de frames
(http://www.w3.org/TR/REC-html40/present/frames.html).
Los frames es un mecanismo soportado por HTML que nos permite dividir la página en distintos fragmentos, e indicaremos que HTML se debe cargar en cada uno de estos fragmentos. Es decir, tenemos un HTML que actúa como “contenedor” de otros HTMLs. La resolución de estas “inclusiones” se realiza en el navegador (en cliente, no en servidor). Es decir, es el navegador el que va pidiendo al servidor los distintos fragmentos según va parseando el HTML “contenedor”.
Esta técnica acabó estando un poco mal vista y además no cuadra demasiado bien con cosas como SEO (Search Engine Optimization
http://en.wikipedia.org/wiki/Search_engine_optimization) o URLs amigables (http://en.wikipedia.org/wiki/Rewrite_engine).
3.2. SPI
A día de hoy se puede conseguir recargar partes concreta de la página mediante AJAX
(http://en.wikipedia.org/wiki/Ajax_(programming)).
Esto consiste básicamente en hacer peticiones asíncronas al servidor mediante JavaScript, y con la información obtenida manipular el árbol DOM de la página para repintar parte de esta.
Así aparece una nueva vertiente para el desarrollo web, se trata del SPI (Single Page Interface http://itsnat.sourceforge.net/php/spim/spi_manifesto_en.php)
Con SPI se pretende hacer desarrollos web como los hacíamos en escritorio (VB o Swing, …), usando técnicas como la que comenta nuestro amigo en su pregunta del “Master Page”. De forma que la página siempre es la misma, y lo que hacemos es ir cambiando partes de está página con el uso intensivo de AJAX. Al final lo que estamos haciendo es mantenernos siempre en la misma página e ir cambiando el estado de la aplicación.
En esta técnica el tema del SEO o las URLs amigables tampoco es trivial. Hay soluciones técnicas pero no son ni evidentes ni inmediatas.
3.3. Mi opinión
Yo personalmente no comulgo mucho con esta tendencia (no en su vertiente radical), porque creo que las aplicaciones web no son aplicaciones de escritorio. Ni las técnicas son las mismas, ni los lenguajes, y mucho menos el HTML/HTTP que es con lo que al final
tenemos que lidiar (por lo menos hasta que se invente otra cosa; a ver que tal con el HTML5 http://dev.w3.org/html5/spec/Overview.html 😉
Yo por ahora apuesto por una aproximación mixta, quedándonos con lo mejor de los dos mundos: aprovechar la semántica de los «verbos» de HTTP, de forma que hagamos peticiones GET para todo aquello que no modifica el estado de la página (por ejemplo un listado resultado de una búsqueda) y peticiones POST para todo aquello que modifica el estado del sistema (por ejemplo un alta, una modificación). Con JSF2 podemos conseguir esto usando h:button o h:link para hacer peticioens GET, y h:commandButton y h:commandLink para hacer peticiones POST.
Dentro de esta idea usar AJAX lo más posible para la lógica de presentación (validaciones, cambios en la interfaz por la selección de un elemento concreto, …). Con JSF2 lo tenemos fácil gracias a f:ajax.
Todo esto de forma flexible (nunca seas extremista en ningún sentido), de forma que al final consigas una interfaz usable con un mínimo de esfuerzo. Esto es lo realmente importante ya que es lo que va a percibir el usuario final; al que, por cierto, le importa
bastante poco la tecnología que hayamos usado.
Haciendo SPI o no, lo que si deberíamos usar es un sistema de plantillas en servidor para no repetir las cosas mil veces. Podría ser el típico include de JSP, o en el caso de JSF lo
tenéis fácil con Facelets. Por el echo de que la página se recargue entera no deberíamos preocuparnos demasiado, siempre y cuando nos encargamos de cachear correctamente los js, las imágenes, las css, … de forma que, una vez descargadas al cliente, se las quede el navegador y no las tenga que descargar continuamente.
Si aun así tenemos muchas peticiones sobre la aplicación, podemos llegar a cachear el resultado de procesar las páginas JSF con OSCache o similar, siempre teniendo en cuenta los tiempos de refresco para no dar información desactualizada a nuestros usuarios. Esto sería recomendable hacerlo a posteriori, y siempre después de un profile para detectar donde realmente se está perdiendo el tiempo.
Ya veis que no hay una respuesta única a esta pregunta. Os recomendamos que probéis varias aproximaciones y que os quedéis con la que más cómodos os sintáis y la que mejor se ajuste a vuestra tipología de aplicación. Por ejemplo si estáis haciendo un portal
seguramente no sea demasiado práctico el SPI, pero si lo que estáis haciendo es una aplicación, en este caso el SPI podría tener mucho sentido.
4. Sobre el autor
Alejandro Pérez García, Ingeniero en Informática (especialidad de Ingeniería del Software) y Certified ScrumMaster
Socio fundador de Autentia (Formación, Consultoría, Desarrollo de sistemas transaccionales)
mailto:alejandropg@autentia.com
Autentia Real Business Solutions S.L. – «Soporte a Desarrollo»
