- Comunicación en Interacción entre el Browser y el Server
- Actualización de la pantalla (DOM/AHAH)
- Componentización de la Pantalla y Manejo de Eventos
- Testeo Unitario
- Portabilidad y Cross browser
- Patterns y Errores Comunes
A esto me refiero entre la comunicación que debe exister entre cualquier browser, los diferentes tipos de RPC. En lo que a la comunicación refiere, podemos detectar dos grandes tipos
- Client Pull : En donde el browser siempre hace pedidos al server
- Server Push: En donde el servidor actualiza la UI sin necesidad de que haya un evento desde el cliente.
Obviamente, el primero es el más común y el que se lleva bien con el protocolo HTTP. Aca vienen los diferentes concerns relacionados con el protocolo de comunicación, obviamente aca viene un poco el tema de los tipos de mensajes, tipo de interacción (sincrónica o asincrónica) y tipo de respuesta, esto está muy ligado a la compenentización y al manejo de evento (de componente o global). Para este tipo de concern existe un framework (java) que permite ambos tipos, este es DWR (Direct Web Reomoting) , dicho framework llama al Push, como Reverse Ajax. Y si no queremos aca hablar de algún framework podemos decir que los XML Request, dependiendo del Browser.
Actualización de la pantalla (DOM/AHAH)
Este concern refiere a como la pantalla se va actualizar luego de la interacción entre el browser y el server. Está claro que cada componete debería tener su manera de renderizarse, pero más alla de esa responsabilidad, hay que evaluar en cada caso que tipo de actualización vamos a hacer, es donde aca se debería definir estos tres tipos:
-Pantalla completa, el html se genera en el Server
-Manipulación del DOM, el html es un xml que se manipula por JS en el browser
-Uso de AHAH, este es el conocido innerHtml
Está claro que estos tres métodos pueden utilizarse una misma aplicación, es más, los tres se tienen que usar, deacuerdo al flow de la aplicación y sobre todo la performance y simpleza del código.
Componentización de la Pantalla y Manejo de Eventos
Este es uno de los conceptos más radicales para los que venimos trabajando orientados al MVC 2 o pagina completa u orientado a template. Aca volvemos un par de años atras cuando se desarrollaban GUI totalmente orientada a componentes y eventos, aca es exactamente lo mismo, las aplicaciones RIA posees mas componentes y eventos mucho más complejos. Está claro que aca es donde el tema se comienza a complejizar. No soy un experto en esto, pero es aca en donde los frameworks como Tapestry e implementaciones de JSF comienzan a tener un lugar en las UI Web, y por supuesto no puedo dejar de nombrar a Shale. Es aca en donde hay que tener mucho cuidado con la interacción entre el programador web con el diseñador de contenidos. Todavía no he encontrado una buena manera de poder definir una buena interacción entre ambos.
Testeo Unitario
Que lindo tema... pero que complicado tambien. Yo creo que aca hay que "divider and conquer" más que nunca, lamentablemente más alla de los "record and play" es muy dificil. Este es un campo bastante prematuro y que todavía no está resuelto para aplicaciones MVC 2, menos va a estar para RIA. Yo creo que el camino viene por separar el unit test de RIA en estos concern:
- Event Listeners (validar si el listener asociado con el evento llama al service/command específico)
- Comportamiento del Componente renderizado (como se darán cuenta, no tomo a la pagina como un todo, sino que mi unidad granular es un compoennte, ej. combo, boton, etc)
- Interfaz Completa (si o si creo que Record and Play es el camino, aunque lo odie ya que no me permite mockear nada) Aca estaría bueno poder moquear el acceso al negocio y generar todos los test cases necesarios de interfaz sin trabajar con el modelo... Como? rta. IoC.
- Como el componente se renderiza (uy que feo)
- Smoke Test desde la Interface, como todo, esto tiene que ser automático, miren esta tool, Selelium
Portabilidad y Cross browser
Está claro que este es un punto complicado, hace 7 años que trabajo con JS y esto es un plomo. No solo que el JS tiene que "compilar" sino que tambien tiene que comportarse de la misma manera en los diferentes browsers. Esta es una de las principales desventajas para JS, está claro. Pero por suerte hace un tiempo me comentó, Gona (un colega de IBM), que ya eso se viene solucionando, esto no quiere decir que los browser se pusieron de acuerdo y su interprete se comporta de la misma manera, no, es que ya las librerías de JS, como Prototype (que muchos frameworks de ajax usan como base) ya realmente nos abstraen del problema de portabilidad. Está claro que no este no es un tema menor, incluso unsando prototype se encuentran muchos problemas de portabilidad. Otro factor importante es el tema de los browser que no aceptan JS, y por supuesto tampoco nos permiten AJAX. O sea aca estamos graves problemas, como hacemos para desarrollar una aplicación RIA y que si el cliente acepte JS la aplicación cumpla con los req. funcionales básicos de cualquier aplicación Web.... muy muy complicado... casi que debería ser una capa de UI diferente para manejar cada caso. Y si, no nos queda otra. En algún momento cuando arranque con una proyecto en el Lab de Sistemas, vamos a encarar ese problema y seguramente publiquemos algún paper.
Patterns y Errores Comunes
Este tema está (o estoy) muy poco maduro, tengo poca experiencia en desarrollos RIA, el solo hecho de trabajar en Web nos acerca muchos patterns, pero específicos de RIA, todavía yo no puedo decir nada, creo que aca hay factores que tenemos que tener en cuenta:
- Concurrencia y Sincronización
- Manejos de Errores
- SessionTimeOut
- Performance (Latencia y Throughput)
- me ayudan?
Bueno este es mi opinción de los diferentes aspectos de una aplicación RIA, y tambien es la manera que estamos encarando RIA en el proyecto que estamos trabajando hoy. Espero comentarios, nuevas ideas, correcciónes, etc..
2 comentarios:
Copado el post!, muy al estilo de las clases de APIT (por ejemplo por la palabra Componentización!). Algo que me parece interesante (que no se si esta o no muy relacionado RIA) es la posibilidad de empezar a definir de alguna forma mas abstracta la UI con el objeto de poder reutilizar la renderización de los componentes en distintos dispositivos (Moviles, Browsers, PDAs, etc). Entiendo que otras alternativas a Ajax por ejemplo serían Flash o XAML (Reinvención de MS de flash??). Por ahí estuve leyendo a algunos que sostienen que Ajax (js) es algo que esta destinado a morir. Bueno, te dejo esas inquietudes por si te sirven para seguir posteando. Saludos!
Muy buen punto, el concepto de tener templates diferentes para que cada componente pueda renderizarse en diferentes dispositivos, con ese approach se podría pensar que RIA puese ser algo como un render kit, ya que los mismos coponentes se podrian tener que renderizar para un browser que no soporte js o un poco viejo.
Con respecto a Flex, la verdad que viene sumando, vi cosas muy interesantes, ya voy a postear algo, aunque por ahora no me tira mucho el tema de tener que se tan propietario. Con respecto a JS, nose, no creo que se muera, nunca se sabe... en mi opinión tiene mucho futuro y potencial, eso si, si los browsers no se mandan mocos y no permiten la portabilidad, pero al ritmo que vamos MS que es el principal prohibidor de todo esto tiene su framework ajax (se llama "atlas" me parece) tambien, por lo tanto no se que nos deparará el futuro.
Publicar un comentario