Varios meses muy atareado. Vuelvo de dos semanas de vacaciones, y llega el momento de rematar el trabajo...Extendiendo dos modelos construídos con Plex, con una presentación basada en C++ y servicios llamados en iSeries-RPG400/RPGIV, para que puedan disponer una presentación Web. La parte Web, hecha con Webclient (ADC Austin), con su extensión Java/Javascript disparada a través del uso de Eclipse. Este es el segundo proyecto organizado fuera de CA usando Eclipse como un mediador para extender Plex (el primero, el open source encarado por Christopher Smith para usar las facilidades de test y depuración de Eclipse/java con Plex).
En fin, el proyecto funciona...A partir de los modelos diseñados para C++/RPG, creamos una variante Java-WebClient que separa el diseño de paneles (y reportes) en la variante, de tal forma que conviven en el mismo modelo dos paneles distintos; con sólo configurar una variante u otra, generamos paneles para cada lenguaje. La lógica la hemos desarrollado en la variante base (C++), usando metaoperaciones para separar las diferencias de implementación entre ambos lenguajes. Luego, el modelo declara en la variante Java-Web dos elementos: nueva herencia que indica qué tipo de paneles Web se construirán, y el lenguaje Java de implementación.Así, se genera distinto código según la variante configurada.
¿Cómo pasa el código de Plex a Eclipse? El código Java generado en Plex es tomado por scripts escritos en Ant y transferido a un proyecto JEE en Eclipse. El área de trabajo en Eclipse se compone de un proyecto Ant , uno Java, un servlet WebClient, y un proyecto Web (JEE). Por cada panel el proyecto java construye una función (servlet) que enlaza la presentación y los eventos interactivos con el código Javascript que ejecutará en tiempo real. El código javascript (Dojo + Json) está enlazado a plantillas tipo que son invocadas al indicarle al modelo que se hereda de determinados patrones Webclient.
Teóricamente, (y lo he puesto en práctica rudimentariamente) cada plantilla es factible de ser creada por el modelador. Mientras nos familiarizamos, nos hemos sujetado a utilizar las que están disponibles, modificando algunos aspectos de éstas, sea en las directivas de las plantillas o en las hojas de estilo asociadas.
El último paso es configurar los ficheros properties y adecuar el fichero de configuración de la aplicación Web (Web.xml), crear un paquete War, e implementarlo en Websphere (este paso resultó sorprendentemente más fácil de hacer de lo que esperaba).
Es decir, Plex es extendido en este caso agregando enteramente el código Ajax en un proyecto Eclipse, y asociándolo con el código Plex java mediante un servlet. Así, no sólo extendemos Plex a aplicaciones Web que se basan en Ajax, sino que podemos usar las facilidades de testeo y depuración de Eclipse: en una sesión normal, testeo el código java directamente en el ambiente Eclipse, y, usando Tomcat o Jetty, el código Web. Si hay diferencias de comportamiento, a revisar...(Consola de Java, Log de actividad del servlet).
Generalizando, la utilización de Eclipse por distintos grupos de desarrollos de Plex, puntualiza la potencia disponible a partir de esta combinación. Existen infinitos recursos disponibles en Eclipse, particularmente el Eclipse Modeling Framework, y las extensiones que lo utilizan (UML2, OCL). Aquí se ha mencionado a MODISCO (Model Discovery), como un elemento de mucho interés que debería ser seguido con atención. Y otro más debería ser seguido con máximo interés: Xtext, que por su versatilidad podría ser usado para extender Plex de muy distintas maneras.
Es mi parecer, y ojalá estuviera en mis posibilidades explorarlo, que es posible extender Plex para muy distintos alcances, entre ellos algunos que en más de una oportunidad fueron desestimados basados en el alcance estricto de sus generadores.
A modo de confirmación, dos discusiones (1,2) de finales de este mes muestran que es posible incluír IPhone o IPad entre las aplicaciones generables a partir de modelos Plex.
No hay comentarios.:
Publicar un comentario