Desarrollando con Flex, flexmdi, PureMVC, BlazeDS, Spring, JPA, Hibernate,... (parte 3)

Aunque el artículo anterior habrá sonado un poco descorazonador, tengo que confesar que la aplicación está casi terminada. Pronto pasará a estar en producción y podremos comprobar el éxito o el fracaso -espero que sea lo primero- del producto desarrollado y de las decisiones que he ido tomando a lo largo del proyecto.

Algunas cosas que han cambiado con respecto a lo previsto:

• Estoy utilizando MySQL como base de datos, para la fase de desarrollo. La aplicación en producción funcionará contra un Oracle 10g. El coste de crear una aplicación que permita seleccionar una base de datos u otra ha sido... "cero"!!! (gracias JPA).
• Estoy utilizando Tomcat 5.5 como "servidor de aplicaciones", para la fase de desarrollo. La aplicación en producción funcionará sobre un Oracle Application Server (realmente un OC4J 10.1.3). En mis pruebas funciona, además, perfectamente sobre un JBoss 4.2. El coste de crear una aplicación que permita seleccionar un servidor de aplicaciones u otro ha sido... "cero"!!! (gracias J2EE).
• Como entorno de desarrollo utilizo, exclusivamente, Eclipse y aunque tengo montado Flex Builder (la versión Trial) como un plugin de éste... apenas lo utilizo, al menos intento no utilizarlo. Me las apaño con Apache Ant y con las Flex Ant Tasks para compilar mi librería SWC y mi proyecto SWF. No he encontrado ninguna herramienta Open Source y/o gratuita con la que pueda desarrollar con Flex (parece mentira a estas alturas).
  
• Del resto de los productos que pretendía utilizar, menos de la librería flexmdi (y creo que me arrepentiré de no haberlo hecho) he hecho uso de TODOS ellos. Esto se llama... puntería ;-)
• Además he incorporado JasperReports y su diseñador de informes iReport para generar informes, que exporto a PDF y que muestro desde la aplicación Flex (realmente los muestro sobre el navegador web). El tema de los informes en Flex debería estar un poco mejor tratado.... debería estar tratado, al menos.
• Una ayuda muy especial para depurar nuestro código es ThunderBolt, una extensión para "tracear" aplicaciones Flex sobre la consola de Firebug del "add-on" para Firefox.

Desarrollando con Flex, flexmdi, PureMVC, BlazeDS, Spring, JPA, Hibernate,... (parte 2)

Después de 2 meses sin dar señales de vida he querido, al menos, escribir sobre la marcha de mi primer proyecto Flex. La verdad es que con esta experiencia estoy teniendo sentimientos contradictorios según el día.

Hay días que me digo: "que bueno haber descubierto Flex". Hay otros que me desconsuelo y me digo: "en qué demonios estaba yo pensando cuando me metí en esto de los RIAs".

Creo que el principal problema es que había puesto demasiadas expectativas.

No nos engañemos, el desarrollo de RIAs era ya posible, estaba en nuestra manos, desde el principio de los tiempos.

No nos engañemos el desarrollo de RIAs para la web estaba en nuestras manos desde los primeros días JAVA, mediante la creación de applets que hacían uso del vetusto API AWT. Yo he visto hace más de 10 años aplicaciones, incluso participado en ellas, alucinantes, que no tenían nada que envidiar a las actuales aplicaciones Flex.

Flex ha venido a recordarnos que esto es posible, mejora un poco -faltaría más- las dificultades que nos encontrábamos con el AWT y añade bonitas animaciones y sombras a nuestros componentes.

Respecto a esto, creo que Flex está poniendo mucho más énfasis en que podamos cambiar los estilos y las "pieles" de nuestras aplicaciones y componentes, hasta extremos innecesarios, que el potenciar aquello que realmente nos hace la vida más fácil a los desarrolladores de productos para la web. Creo que deberían buscar un equilibrio...

Desarrollando con Flex, flexmdi, PureMVC, BlazeDS, Spring, JPA, Hibernate,... (parte 1)

Estoy desarrollando mi primera aplicación con Flex y quería ir comentando mis "desavenencias" en este blog, por si os sirve -o me sirve a mi- de algo, en un futuro, mi experiencia.

El "producto" es una sencilla aplicación Flex que, previa autenticación del usuario y una vez comprobados sus privilegios, nos permitirá mantener la información guardada en una base de datos, mediante sencillos formularios.

El primer problema es encontrar el conjunto de herramientas que me van a acompañar en el desarrollo de este producto. Esta es mi lista, creo, definitiva:

1. Base de datos: aunque trabajo normalmente con Oracle, el producto podrá funcionar con cualquier base de datos del mercado para la que tengamos un driver JDBC disponible. Es decir, casi todas las existentes o conocidas.
2. Servidor de aplicaciones: casi toda la lógica de negocio de mi aplicación correrá del lado del servidor. He decidido, de momento, por aprovechar al máximo mi conocimiento en este campo, trabajar con la plataforma J2EE. El servidor de aplicaciones que utilizaré es JBoss, pero la aplicación funcionará en cualquier otro servidor, compatible J2EE, sin dificultad. Incluso, lo haré funcionar en un sencillo contenedor Apache Tomcat.
3. Como herramientas de desarrollo, seleccionaré Eclipse y me aprovecharé, también, de la ventaja que supone poder utilizar el Flex Builder en modo trial durante unos meses.
4. Para acceder a la base de datos y desarrollar la lógica de negocio más dura, del lado del servidor, he decidido utilizar la siguiente combinación: algunas clases del proyecto AppFuse (más concretamente la appfuse-jpa.jar y la appfuse-service.jar), el framework Spring y finalmente como implementación de JPA (persistencia Java) he seleccionado Hibernate (pero servirían también Toplink u OpenJPA).
5. Para acceder desde Flex a los POJOs, los POJOs que desarrollaré del lado del servidor de aplicaciones, me he decidido por BlazeDS, por su madurez y potencia accediendo a objetos remotos. Además integraré BlazeDS con Spring de forma muy sencilla, con una factoría especial (llamada SpringFactory)... ya os contaré cómo. Esta factoría está disponible dentro de otro proyecto de integración llamado "RemoteDestination annotation for Spring".
   
6. He decidido utilizar para la parte cliente (la desarrollada con Flex) un framework para construir aplicaciones basadas en el modelo MVC (model-view-controller). He seleccionado PureMVC, que tiene un "port" para Flex y que, aunque al principio me ha costado entender su funcionamiento, creo que le sacaré bastante provecho.
7. Seguramente utilizaré, a futuro, múltiples librerías SWC. de momento me he descargado la flexmdi (no puedo vivir ;-) sin crear ventanas en modo MDI en mis aplicaciones). Quizá la utilicé o quizá no, ya veremos.
   
8. Por supuesto, necesitaré el SDK de Java (una versión 5.0 ó superior) y el SDK de Flex (una versión 3 o superior).

Intentaré dejar en algún sitio, próximamente, un esqueleto de aplicación con todo esto en un paquete, para que sea más fácil empezar con el desarrollo.

Trabajar con ficheros XML, diferentes opciones

Como sabéis, los más potentes validadores XML y transformadores XSLT son los navegadores que tenemos instalados en nuestros equipos: IE, Firefox, Opera, etc.

Arrastrando sobre ellos un XML nos lo validan, nos lo transforman (si hay un XSLT asociado), nos lo muestran en forma de árbol, nos permiten navegar por sus nodos, etc.

No necesitamos instalar nada para ello!!!

Si no es suficiente:

Editores XML:

1. ECLIPSE: de serie incluye un sencillo editor XML, pero podemos "pegarles" otros más potentes mediante plugins, como el XMLBuddy.

Ver: http://www.eclipse.org
Ver: http://xmlbuddy.com/2.0/products.html

2. FOXE: muy sencillo (para instalar con un simple zip), consume muy pocos recursos y más que suficiente, la mayor parte de las veces. Yo lo utilizo mucho.

Ver: http://www.firstobject.com/dn_editor.htm

3. WMHELP XMLPAD: un poco más potente que el anterior.

Ver: http://www.wmhelp.com/download.htm

4. Y de pago tenemos... OXIGEN y ALTOVA XMLSPY: son dos de los productos más maduros, famosos y profesionales del mercado.

Trabajar con XML (fundamentalmente con APIs JAVA) :

1. Java incorpora un API (JAXP) en su JVM para trabajar con ficheros XML.

2. También son muy interesantes los proyectos XALAN y XERCES de Apache, que tienen "ports" en Java y en C++.

3. A mi, personalmente, me gusta mucho DOM4J (http://www.dom4j.org) que es el que yo utilicé, en su día, para los proyectos de la empresa donde trabajo.

4. Uno de los APIs Java más interesantes lo proporciona, también, Apache en su proyecto commons-digester (http://commons.apache.org/digester). Este API te permite mapear ficheros XML a clases Java.

Este proyecto es utilizado internamente por muchos de los productos con los que trabajamos, día a día, y que utilizan XML como ficheros de configuración, por ejemplo.

5. Hay más: JDOM (http://www.jdom.org), Jaxen (http://jaxen.org) que es un motor XPath, etc.

Generar ficheros XML en nuestras aplicaciones:

DOM4J y JDOM (y otros) permiten generar ficheros XML mediante la exportación a texto (por ejemplo) de documentos XML que vamos generando con estos APIs: creando el objeto documento, generando los nodos, enganchándolos al documento (o a otros nodos) y luego "serializando" este objeto documento a un fichero de texto.

A veces resulta tedioso y es más sencillo generar un fichero de texto, como un fichero de texto más de los que genera nuestra aplicación, que cumpla con las reglas de un fichero XML (claro está).

Proyectos, gestión, gestores y programadores

Me he encontrado un libro gratuito y en castellano, en:

http://escolaxaviersoto.org/edicions/E3.pdf

Se llama "Dirección de grupos y reuniones. Gestión del tiempo."

Así que, creo que, NO nos interesa mucho ;-) no sea que empecemos ahora a hacerlo bien (lo de dirigir grupos, dirigir reuniones y gestionar el tiempo).

Además os invito a leer este otro pequeño artículo (me ha resultado interesante por expresar una teoría tan "real como la vida misma" de forma tan sencilla):

http://www.navegapolis.net/content/view/761

Según esta teoría, los proyectos que solo necesitan previsión de fechas y costes requieren de metodologías más tradicionales, con gestores que controlen a su equipo y den "palos" y con programadores a los que NO les guste su trabajo (que lo hagan solo por dinero, vamos).

Sin embargo, los proyectos que se preocupan realmente por el VALOR del producto requieren de metodologías más ágiles, con gestores que velen por su equipo y realmente comprometidos y con programadores que trabajen en "esto" por algo más que por dinero (porque realmente les guste su trabajo).