Janus: Un Generador De La Vista De Roma Framework Basado En Plantillas

Janus: un Generador de la Vista de Roma Framework basado en Plantillas Pablo Mart´ın, Guillermo Hern´andez

Carlos A. Iglesias

Luca Garulli, Giordano Maestro

Division I+D+i Division I+D+i Division I+D+i Inform´atica Gesfor (Grupo Gesfor) Germinus XXI (Grupo Gesfor) Asset Data s.r.l. Avda Manoteras, 32 28050 Madrid Avda Manoteras, 32 28050 Madrid Via Rhodesia, 34 00144 Roma {pmartinb,ghernandezc}@grupogesfor.com [email protected] {luca.garulli, giordano.maestro}@assetdata.it

Resumen—Los enfoques tradicionales de desarrollo de aplicaciones web han mostrado serios problemas de productividad, lo que est´a dando lugar a nueva generaci´on de frameworks web que automatizan en gran medida el desarrollo para aplicaciones principalmente de persistencia de datos. En este proyecto se presenta c´omo la utlizaci´on de plantillas puede facilitar la generaci´on de la capa de presentaci´on en uno de estos nuevos frameworks a´ giles, Roma Metaframework. Este trabajo ha sido desarrollado dentro del proyecto ICT Romulus. La soluci´on, llamada Janus, utiliza un mecanismo de plantillas basado en FreeMarker para extraer informaci´on de los objetos que definen la vista de la aplicaci´on generando una estructura de p´aginas JSP equivalente, y se comunica con el framework mediante una serie de etiquetas Java. Como resultado, Janus permite la generaci´on autom´atica de una interfaz gr´afica personalizable, implementada con JSP, CSS y Javascript, con un tiempo de desarrollo reducido. Palabras Clave—Janus, JSP, Roma, Metaframework, Java, Javascript, FreeMarker, Romulus

I.

´ I NTRODUCCI ON

El Desarrollo Web es una de las a´ reas m´as activas, tanto a nivel nacional, como europeo, pero tambi´en es un a´ rea poco madura debido a la proliferaci´on de frameworks y componentes. En concreto, Java Enterprise Edition es la opci´on preferida por los europeos con m´as del 38.6 % de desarrolladores usuarios de esta tenolog´ıa seg´un los datos de Evans [5]. Este hecho ha provocado que las habilidades requeridas por los desarrolladores web para llevar a cabo un desarrollo software, aumenten, y con ello baje su productividad y la fiabilidad de sus desarrollos. Este problema es particularmente acentuado en el entorno java, en el que el desarrollo de aplicaciones exige multitud de conocimientos de frameworks y tecnolog´ıas (Struts, Hibernate, Java Server Pages, XSLT, JUnit, ...). En este contexto surge el proyecto Romulus [18], cuyo principal objetivo es investigar y desarrollar nuevos m´etodos para aumentar la productividad y la fiabilidad del desarrollo de aplicaciones web en Java. El resto del art´ıculo se estructura como sigue. La secci´on II hace una breve introducci´on al proyecto Romulus donde se encuadra Janus. La secci´on III presenta las necesidades que se pretenden cubrir y las deficiencias que presenta Echo2, seguida de la secci´on IV donde se explica la implementaci´on de Janiculum como mecanismo actual para mostrar la vista de las aplicaciones en Roma. A continuaci´on, en la secci´on V, se exponen las herramientas de generaci´on de plantillas m´as populares y se define la arquitectura de la soluci´on propuesta en la secci´on VI. La secci´on VII ilustra con un ejemplo el

funcionamiento de esta soluci´on y, por u´ ltimo, se recogen las conclusiones y el trabajo futuro en la secci´on VIII. II.

E L PROYECTO ROMULUS

El proyecto ROMULUS [18] tiene el objetivo de contribuir en en el desarrollo de tecnolog´ıas a´ giles para el desarrollo de aplicaciones web en Java. El proyecto investiga en dise˜no dirigido por el dominio (DDD, Domain Driven Design) para aplicaciones web basado en el metaframework Roma, as´ı como en la integraci´on de la tecnolog´ıa de mashups en el ciclo de vida de desarrollo software. En el proyecto participa la gran empresa, Inform´atica Gesfor, como coordinadora, las PYMEs Asset Data, Liferay, IMola e ICI y los centros de investigaci´on: Universidad Polit´ecnica de Madrid y el instituto DERI. Romulus propone la mejora de la productividad del desarrollo de las aplicaciones web, as´ı como de su calidad, mediante cuatro objetivos: Dise˜no Dirigido por el Dominio basado en un Metaframework. Como se presenta en la secci´on II-A, el proyecto investiga en el uso de un metaframework y en centrar los esfuerzos en el modelado del dominio, empleando t´ecnicas de generaci´on autom´atica de c´odigo para los frameworks Java m´as populares. Desarrollo Orientado a Mashups. Reutilizaci´on de componentes y servicios disponibles para el desarrollo y extensi´on de aplicaciones. Introducci´on de objetivos no funcionales (seguridad, fiabilidad, an´alisis de prestaciones) en todo el ciclo de vida. Investigar en el balance adecuado entre tecnolog´ıas cliente, tecnolog´ıas servidor, y tecnolog´ıas de scripting. El proyecto investiga en la definici´on de buenas pr´acticas y patrones de dise˜no para repartir adecuadamente la carga entre estos puntos. Estos objetivos suponen, en t´erminos de productividad, una reducci´on del 20 % en tiempos de desarrollo de aplicaciones web est´andar y un 30 % menos de conocimientos requeridos, bas´andose en el n´umero de librer´ıas necesarias y su complejidad para implementar una serie de tareas est´andar [17]. II-A.

Roma Metaframework

Roma [6] propone un nuevo paradigma para el desarrollo de aplicaciones web tomando ventajas de las nuevas tendencias en ingenier´ıa de software tales como el dise˜no

dirigido por dominio (Domain Driven Design) combinado con metodolog´ıas de desarrollo a´ gil y algunos de los principios de Ruby on Rails [16]. Para lograr este objetivo funciona como un meta-framework que permite desarrollar aplicaciones utilizando cualquier framework como una pieza intercambiable, desacoplada de la aplicaci´on en s´ı. Esto permite la integraci´on de las nuevas tecnolog´ıas sin modificar el dominio ni la l´ogica de la aplicaci´on y tambi´en aumentar las tasas de productividad en el desarrollo de software. Roma propone tres niveles de abstracci´on: El Dominio, definido por el desarrollador y que tiene que ver con el modelo de negocio de la aplicaci´on. Los Aspectos, implementados por el framework (persistencia, vista, internacionalizaci´on, sesi´on, monitoreo, flujo, etc). Los M´odulos, que proporcionan facilidades para acelerar el desarrollo, promoviendo la reutilizaci´on de c´odigo (persistencia, login, gesti´on de usuarios, integraci´on con IDEs, etc.). Las caracter´ısticas principales de Roma son: Roma est´a basada totalmente en POJOs (Plain Old Java Objects) Todos los aspectos son orientados a objetos: desde el modelo a la vista. Promueve el uso del dise˜no dirigido por dominio (Domain Driven Design). Funciona con convenciones del estilo de Ruby On Rails: mucho menos c´odigo que escribir y mantener y mayor uniformidad de los proyectos. Las aplicaciones son portables a otros frameworks gracias a la orientaci´on a POJOs. Permite modificar directamente el framework, se pueden desarrollar m´odulos adicionales o extender los ya existentes. Est´a basado en Spring Framework pero se pueden extender otros frameworks. Roma proporciona al usuario soporte autom´atico en cada capa y aspecto de su aplicaci´on, desde interfaces web de usuario din´amicas y persistencia, hasta funcionalidad de informes, desarrollo de portlets y tecnolog´ıas sem´anticas. Proporciona interfaces de comportamiento muy gen´erico llamadas “Aspectos”. Los Aspectos incluyen los casos de uso m´as comunes, y permiten hacer independiente el c´odigo de la tecnolog´ıa, con lo que en caso de futuras migraciones de tecnolog´ıa, el proceso ser´a m´as r´apido y sencillo. La figura 1 muestra los aspectos implementados por Roma. En este art´ıculo se describir´a el m´odulo Janiculum, que implementa el aspecto View, y se presentar´a Janus como una alternativa para la vista de las aplicaciones. III.

N ECESIDADES

La interfaz gr´afica de las aplicaciones es un aspecto complejo que, siguiendo la filosof´ıa de Roma, debe ser independiente de la l´ogica de la aplicaci´on y, adem´as, debe permitir el uso de diferentes tecnolog´ıas subyacentes. Roma proporciona por defecto una interfaz gr´afica para las aplicaciones generada con la tecnolog´ıa de Echo2. Echo2 es una plataforma basada en AJAX que ofrece una capa de Java que genera din´amicamente Javascript. Con esto permite la construcci´on de aplicaciones

Figura 1. Aspectos de Roma

web aprovechando las capacidades de los clientes ricos. Las aplicaciones se realizan enteramente en Java mediante una API orientada a componentes y dirigida por eventos [13]. La ventaja que proporciona esta soluci´on es su potencia y la total abstracci´on de la capa web. Sin embargo tiene una serie de deficiencias que motivan el desarrollo de otra soluci´on para generar la vista de las aplicaciones web en Roma. La primera de sus limitaciones es la gesti´on de eventos. Al ejecutarse sobre un servidor, los eventos s´olo se env´ıan desde un cliente bajo ciertas circunstancias, por ejemplo, al hacer clic sobre un bot´on. Esto hace que para ciertas operaciones, como por ejemplo autocompletar o desplazar el rat´on sobre un elemento, sea necesario crear componentes personalizados, lo cual influye negativamente en la productividad de la aplicaci´on. Adem´as Echo2 genera identificadores, dentro del c´odigo Javascript, que cambian con cada sesi´on lo que hace que dicho c´odigo generado no se pueda modificar. Otro problema de Echo2 es la generaci´on de URLs ya que sus aplicaciones s´olo cuentan con una URL global lo que resulta negativo para posicionarse en buscadores. Finalmente, el uso de esta plataforma requiere de una formaci´on adicional ya que no se trata de un framework muy extendido y, adem´as, su comunidad est´a decreciendo a˜no tras a˜no. Todas estas limitaciones hacen necesaria la utilizaci´on de otra tecnolog´ıa m´as flexible en la personalizaci´on y que est´e ampliamente difundida para mejorar la presentaci´on y aumentar la productividad. La soluci´on que presenta Janus soluciona los problemas de Echo2 ya que utiliza tecnolog´ıas de CSS y JSP, muy extendidas en el desarrollo de interfaces web, con una gran cantidad de librer´ıas disponibles e independientes de servidor y plataforma. Janus genera una interfaz web en JSP que el desarrollador podr´a utilizar directamente o modificar seg´un sus necesidades. Esta soluci´on permite que la aplicaci´on presente diferentes URLs ya que se genera una estructura de p´aginas JSP similar a la que se genera en frameworks semejantes como Ruby on Rails o Grails donde se utilizan mecanismos de plantillas para generar la interfaz gr´afica de las aplicaciones. IV.

M ODULO JANICULUM DE ROMA

Para solucionar algunos de los problemas de Echo2, dentro de Roma se ha desarrollado un aspecto llamado Janiculum

que traslada los conceptos de Roma a p´aginas din´amicas utilizando standards XHTML y CSS2. Para ello tiene que realizar una correspondencia entre los objetos de Java y las a´ reas definidas en el layout de Roma. Posteriormente se realiza una asociaci´on entre los elementos de la vista y los objetos. Para ello Janiculum realiza las siguientes operaciones: Generar la estructura de la p´agina a partir de la definici´on de las a´ reas de pantalla Generar fragmentos HTML para cada Objeto/atributo/m´etodo Asociar identificadores u´ nicos para cada Objeto/atributo/m´etodo Realizar la conversi´on entre los par´ametros de la petici´on (Strings) y los valores del atributo del objeto Identificar qu´e acci´on se ha realizado en el cliente e invocar el m´etodo correspondiente en el objeto ubicado en el servidor IV-A. Definici´on de a´ reas en Roma Roma permite definir a´ reas donde colocar los diferentes elementos de los POJOs, independientemente de la implementaci´on utilizada para la vista. Estas a´ reas se definen en ficheros XML que se colocan por defecto dentro del paquete view.domain.screen, donde se encuentra la definici´on por defecto main-screen.xml (figura 2): Este archivo permite definir las a´ reas y su colocaci´on dentro de la pantalla [12]. La colocaci´on de los elementos dentro de dichas a´ reas se realiza mediante anotaciones con el par´ametro layout. Por ejemplo la anotaci´on @ViewClass( layout = ”screen://body”) para una clase colocar´a dicha clase dentro del area llamada body. Esto permite definir la colocaci´on de los elementos desde las clases java, sin hacer referencia a ninguna tecnolog´ıa, lo que permite cambiar de Echo2 a JSP u otra tecnolog´ıa sin necesidad de modificar la aplicaci´on.

- Muestra el objeto completo utilizando la renderizaci´on por defecto. Muestra un atributo del objeto. El campo name (obligatorio) debe contener el nombre de dicho atributo mientras que part (opcional) permite especificar c´omo se mostrar´a el atributo: entero, s´olo la etiqueta o s´olo el contenido. - Muestra un m´etodo del objeto. El campo name (obligatorio) debe contener el nombre de dicho m´etodo. Por ejemplo, con la etiqueta: , el taglib generar´a el c´odigo HTML correspondiente al atributo address del objeto que se est´e mostrando. Con esta implementaci´on Roma proporciona una interfaz gr´afica basada en HTML que genera p´aginas din´amicamente a partir de los POJOs. Si un usuario quiere modificar el aspecto de un determinado POJO (Ejemplo.java) puede crear el archivo Ejemplo.jsp y personalizar su vista utilizando las etiquetas proporcionadas por la taglib de Roma. Esto resulta poco productivo porque para personalizar el aspecto de la aplicaci´on ser´ıa necesario crear manualmente el archivo correspondientes a cada POJO. Por ello se ha implementado un mecanismo de plantillas llamado Janus como una alternativa que genere todos estos archivos autom´aticamente y que, adem´as, permita personalizar f´acilmente y desde un u´ nico punto la forma en que los archivos se generan. V.

´ DE PLANTILLAS H ERRAMIENTAS DE GENERACI ON

En esta secci´on se presenta un estudio de las distintas herramientas existentes para la generaci´on de plantillas. Una plantilla [23] es una forma de dispositivo que proporciona una separaci´on entre la forma o estructura y el contenido. Es un instrumento que permite guiar, portar o construir un dise˜no o esquema predefinido. Hay una gran variedad de herramientas para generar plantillas, como por ejemplo: Beilpuz [3], eRuby <s c r e e n xmlns =” h t t p : / / www. romaframework . o r g / xml / roma ” [7], Dwoo [19], Evoque Templating [20], GvTags [8], h2o x m l n s : x s d =” h t t p : / / www. w3 . o r g / 2 0 0 1 [9], etc. / XMLSchema−i n s t a n c e ” Velocity [1] es un generador de plantillas basado en Java x s d : s c h e m a L o c a t i o n =” h t t p : / / www y de sintaxis similar a Javascript. Permite a los dise˜nadores . romaframework . o r g / xml / roma h t t p : / / www web referenciar m´etodos definidos en c´odigo Java. Esto pro. romaframework . o r g / schema / roma−view−s c r e e n . x s d ”> porciona a la p´agina web mayor mantenibilidad, ya que separa el c´odigo del dise˜no, y es una alternativa viable a JSPs o PHP. FreeMarker [15] es una librer´ıa Java que proporciona un generador de plantillas para generar texto. Ha sido dise˜nado para su uso por aplicaciones basadas en servlets y en el modelo MVC (Modelo Vista Controlador) para la generaci´on de p´aginas web HTML. FreeMarker no es un lenguaje de programaci´on, simplemente genera texto a partir de programas java y lo muestra usando plantillas. Si comparamos ambas soluciones, la primera conclusi´on Figura 2. Definici´on por defecto de las areas en main-screen.xml que se puede extraer es que Velocity es una herramienta m´as simple y ligera pero con un lenguaje de plantillas menos IV-B. Taglib de Roma potente que no permite tantas operaciones como FreeMarker Como se ha descrito anteriormente Roma proporciona una [14]. Adem´as Velocity hace un uso directo de los m´etodos librer´ıa de etiquetas o taglib (roma.tld) que permite la comu- de los objetos java y mueve tareas de presentaci´on al c´odigo nicaci´on entre la vista y el controlador generando c´odigo con del controlador lo que contradice los principios del patr´on los identificadores un´ıvocos que utilizar´a internamente Roma. MVC. FreeMarker es m´as estricto con esto, lo que puede Esta taglib dispone de tres etiquetas b´asicas: generar problemas con algunas operaciones, pero el html

generado es m´as correcto. La mayor ventaja de Velocity frente a FreeMarker es su comunidad mucho mayor y el soporte de Apache. Adem´as, al ser m´as simple, es tambi´en m´as r´apido que FreeMarker en algunas operaciones. Sin embargo FreeMarker ofrece una serie de caracter´ısticas que no pueden ser realizadas con Velocity de forma trivial. Las m´as importantes de estas caracter´ısticas son las mejores macros, la capacidad de utilizar las bibliotecas de etiquetas JSP personalizadas en plantillas o trabajar directamente sobre objetos de Python y el uso de namespaces. Con FreeMarker se puede convertir tambi´en plantillas de Velocity a plantillas de FreeMarker gracias a una herramienta propia [22]. Ambos mecanismos de plantillas son similares para las operaciones b´asicas y tienen buen rendimiento con plantillas peque˜nas, si bien un factor a tener en cuenta es que FreeMarker es m´as r´apido a la hora de procesar plantillas grandes. Por tanto, la potencia de FreeMarker y su elegancia lo convierten en una mejor opci´on para su integraci´on con Roma. VI.

´ DE LA ARQUITECTURA Y SOLUCI ON ´ D EFINICI ON

El componente Janus genera p´aginas JSP a partir de los objetos java de la aplicaci´on y utiliza tecnolog´ıa de CSS2 para la apariencia. Para la integraci´on con el metaframework de Roma se utilizan anotaciones java [21] y las etiquetas proporcionadas por el taglib de Roma (roma.tld). Para esta generaci´on de c´odigo, Janus utiliza FreeMarker como mecanismo de plantillas e integra tecnolog´ıa de Javascript para mejorar la presentaci´on, mediante la utilizaci´on de JQuery UI [2]. La Figura 3 muestra la estructura b´asica del m´odulo y el flujo de informaci´on para generar el c´odigo jsp final. VI-A. Definici´on de Plantillas Din´amicas para Roma Este apartado recoge la definici´on de plantillas din´amicas para Roma basadas en FreeMarker que facilitan la adaptaci´on de las vistas de una aplicaci´on basada en el metaframework Roma. Gracias a la integraci´on de FreeMarker con Java, se ha realizado una biblioteca de etiquetas o taglib de Roma que permite la comunicaci´on de la vista con el modelo, lo que posibilita la generaci´on de diferentes vistas cambiando u´ nicamente estas plantillas de FreeMarker. La implementaci´on por defecto de la plantilla de Janus para Romulus organiza el c´odigo de los archivos JSP generados colocando en una secci´on los atributos del objeto, cada uno dentro de un

. A continuaci´on, en una nueva secci´on, se colocan los m´etodos del objeto. La figura 4 muestra un

Figura 3. Flujo de informaci´on de Janus

fragmento de esta plantilla con la generaci´on de etiquetas para los m´etodos y atributos del objeto utilizando la taglib de Roma. ... <# l i s t f i e l d s a s f i e l d n a m e> ...

${ c l a s s n a m e } a c t i o n s <# l i s t a c t i o n s a s a c t i o n n a m e> ... Figura 4. Fragmento de la plantilla por defecto de Janus para Romulus

El c´odigo resultante generado con esta plantilla presentar´a los atributos y los m´etodos en diferentes columnas como muestra la figura 5. VI-B. Configuraci´on de Plantillas Din´amicas para Roma Una plantilla de Romulus permite los siguientes constructores: Date. Las fechas se muestran con el calendario JQuery UI Datepicker. ContainerPage. Esta clase de Roma se muestra utilizando los tabs de JQuery UI. Esto se puede configurar mediante el archivo constructors.xml que permite definir las asociaciones entre constructores y elementos de JQuery UI. Adem´as de esta estructura de los JSPs generados, v´alida para cualquier objeto, Janus tiene un comportamiento espec´ıfico para las clases que Roma genera autom´aticamente

Figura 5. Estructura de los JSPs generados con la plantilla de Romulus

para facilitar las tareas de creaci´on, lectura, actualizaci´on y borrado (CRUD). Para estas clases la generaci´on de c´odigo est´a optimizado para una mejor usabilidad mostrando un filtro de b´usqueda en la columna izquierda y los resultados, junto con las operaciones CRUD en la de la derecha como muestra la figura 6. En el futuro se podr´a definir una biblioteca de elementos para el cliente (Javascript, CSS, ...) de forma que se puedan establecer f´acilmente correspondencias entre estos elementos de la biblioteca y los elementos del POJO. Estas correspondencias servir´an para definir perfiles que permitir´an a la aplicaci´on ofrecer diferentes vistas dependiendo del perfil del usuario. VI-C. Estructura y funcionamiento Para conseguir la independencia de la vista en las aplicaciones en Roma se define la interfaz a trav´es de objetos Java (POJOs) con anotaciones localizados dentro de un paquete espec´ıfico llamado view [11]. El componente Janus crea una estructura de archivos JSP paralela a la existente en dicho paquete de forma que cada objeto java de ese paquete (o bien aquellos que el usuario elija) tengan un archivo JSP correspondiente. Esta estructura de archivos JSP tiene una jerarqu´ıa al igual que los objetos java de forma que el nivel m´as alto est´a representado por la clase Object.jsp que Roma provee por defecto. Estos archivos jsp se colocan en un directorio dentro de la estructura de directorios que Roma crea para cada aplicaci´on. La Figura 7 muestra esta estructura. Dentro del directorio dynamic se encuentran las hojas de estilo y los archivos jsp correspondientes a los objetos Java. En el directorio static se encuentran los archivos jsp, hojas de estilo y librer´ıas correspondientes a las tecnolog´ıas externas que se quieran integrar en el proyecto. En este caso se trata de la librer´ıa de Javascript JQuery UI [2] y la librer´ıa de CSS Yaml [10]. El comportamiento de Roma para mostrar un objeto consiste en buscar un archivo jsp cuyo nombre sea igual al nombre de la clase de dicho objeto acabado en .jsp. Si existe, Roma utilizar´a este archivo para mostrar el objeto y, si no, ir´a ascendiendo por la estructura jer´arquica hasta hallar el jsp adecuado o llegar a Object.jsp quien mostrar´a el objeto de la forma definida por defecto. El componente Janus crea archivos jsp a partir de objetos java de forma que se puedan modificar f´acilmente sin

Figura 7. Estructura de directorios para los archivos JSP

necesidad de compilar el c´odigo fuente de la aplicaci´on. Para ello hace uso del taglib de Roma que genera el c´odigo html adecuado para los atributos y m´etodos del objeto que se va a mostrar, con los identificadores un´ıvocos que Roma podr´a utilizar para su funcionamiento interno. Este taglib se incluye en los archivos JSP que se generan con Janus de forma que para generar el c´odigo correspondiente a los atributos y los m´etodos basta con poner la etiqueta correspondiente del taglib dentro del archivo JSP generado. El funcionamiento de Janus para generar c´odigo JSP es el siguiente: mediante introspecci´on se recorre el objeto que se desea mostrar a˜nadiendo al modelo de datos de FreeMarker todos sus m´etodos y atributos. Posteriormente la plantilla JSPTemplate.ftl accede a este modelo de datos organizando los atributos y los m´etodos con las etiquetas correspondientes del taglib de Roma: roma.tld. La ventaja de este comportamiento es que el usuario puede modificar la plantilla consiguiendo cambiar la forma en que se generan los archivos JSP finales. Concretamente, se pueden integrar librer´ıas de Javascript para mejorar la apariencia de los JSPs generados. Para la implementaci´on del Janus se ha incluido tecnolog´ıa de JQuery UI [2] para organizar los atributos y los m´etodos en diferentes pesta˜nas, as´ı como para el renderizado de algunos tipos de datos como por ejemplo los atributos de tipo Date que son mostrados utilizando el calendario JQuery UI Datepicker. Adem´as se ha incluido tecnolog´ıa de Yaml [10] para el dise˜no de las columnas.

Figura 6. Estructura de los JSPs para las clases CRUD de Roma

Esta soluci´on proporciona flexibilidad para la implementaci´on de la interfaz gr´afica por parte de los desarrolladores ya que pueden retocar individualmente los jsp’s generados mientras que se reduce el tiempo de desarrollo al permitir modificar el c´odigo de todos los archivos jsp desde un u´ nico punto y sin necesidad de compilar. La siguiente secci´on muestra un ejemplo del uso de Janus para crear la interfaz de una aplicaci´on.

VII.

´ O FUTURAS E JEMPLO DE APLICACI ON APLICACIONES

El proyecto Scrooge [4] es un proyecto que se utilizar´a como demostrador del proyecto Romulus y que esta desarrollado en parte con Romaframework. El esqueleto de la aplicaci´on est´a creado con Romaframework. Como se ha explicado anteriormente, la tecnolog´ıa Echo2 es muy poco flexible para realizar cualquier cambio en el estilo de las aplicaciones, al estar escrita la interfaz directamente en c´odigo java, de modo que se ha utilizado el m´odulo Janus para generar una vista en JSP, a partir de cada objeto, mucho m´as flexible, con lo que se permite mayor personalizaci´on a los dise˜nadores web, ya que pueden utilizar JQuery para conseguir aplicaciones web m´as vistosas. La figura 8 muestra el aspecto de la interfaz de Scrooge.

Figura 8. Interfaz de Scrooge, desarrollada con Janus

El proyecto Scrooge, aun en fase de desarrollo, hace uso de tecnolog´ıas web 2.0, AJAX y JQuery por lo que utilizar´a todas las facilidades aportadas por Janus. La soluci´on Janus ha sido dise˜nada para su uso con el metaframework Roma pero tambi´en puede ser utilizada en otras soluciones que utilicen objetos java para definir la interfaz gr´afica o aquellos frameworks que generen autom´aticamente la interfaz gr´afica a partir del modelo como por ejemplo Ruby on Rails o Grails. Un mecanismo de plantillas como Janus adaptado a estos entornos permitir´ıa la personalizaci´on de la interfaz por defecto proporcionada por estos frameworks, as´ı como la integraci´on de nuevas tenolog´ıas de presentaci´on. VIII. C ONCLUSIONES Y T RABAJOS F UTUROS En este art´ıculo se ha presentado el generador de plantillas Janus, desarrollado para Romaframework, dentro del proyecto europeo Romulus, aun en fase de desarrollo. El trabajo ha expuesto los diferentes motores de generaci´on de plantillas existentes en la actualidad, centr´andose en los dos m´as interesantes (Velocity y FreeMarker), comentando sus similitudes y diferencias. Posteriormente se ha definido la arquitectura del m´odulo Janus y se ha mostrado un caso de uso del mismo. En el futuro se aplicar´a el m´odulo Janus a otros demostradores y se desarrollar´a una API Javascript para una mayor facilidad en el desarrollo. Adem´as se implementar´an varios estilos mediante plantillas que permitir´an la creaci´on de temas personalizados seg´un el perfil del usuario.

AGRADECIMIENTOS El m´odulo Janus ha sido desarrollado para Romaframework, dentro del proyecto europeo Romulus ICT-2007.1.2, financiado por la Comunidad Europea dentro del marco Seventh Framework Programme y en fase de desarrollo desde enero de 2008. R EFERENCIAS [1] Apache. The apache velocity project, 2009. Disponible en http://velocity.apache.org/. [2] P. Bakaus and the jQuery UI Team. Jqueri ui project, 2009. Disponible en http://jqueryui.com/. [3] Beilpuz. Herramienta beilpuz, 2009. Disponible en http://beilpuz.getmike.de/doku.php. [4] S. Consortium. Scrooge, 2009. Disponible en http://scrooge.germinus.com. [5] E. D. Corporation. Evans reports, official site, online. available:, 2007. [6] A. creativity Solutions. Roma framework, the new way to conceive web applications, 2009. Disponible en http://www.romaframework.org/. [7] eRuby. Herramienta eruby, 2009. Disponible en http://en.wikipedia.org/wiki/ERuby. [8] GvTags. Herramienta gvtags, 2009. Disponible en http://www.gvtags.org/. [9] h2o. Herramienta h2o, an elegant php template engine, 2009. Disponible en http://www.h2o-template.org/. [10] D. Jesse. Yet another multicolumn layout — an (x)html/css framework, 2009. Disponible en http://www.yaml.de/en/. [11] G. M. Luigi Dell’Aquila, Luca Garulli. Roma <meta> framework handbook, 2009. Disponible en http://www.romaframework.org/doc/RomaHandbook.pdf. [12] T. Meeks. Comparing the google web toolkit to echo2, 2006. Disponible en http://www.theserverside.com/news/thread.tss?thread id=40804. [13] NextApp. Echo2 web framework, 2009. Disponible en http://echo.nextapp.com/site/echo2. [14] F. project. Freemarker versus velocity, 2009. Disponible en http://freemarker.org/fmVsVel.html. [15] F. project. Fremarker: Java template engine library - overview, 2009. Disponible en http://freemarker.org/. [16] A. Protopsaltou. Model driven development with ruby on rails, it university of g¨oteborg, 2004. [17] Romulus. Annex i, description of work, 2007. From the Seventh Framework Programme Theme ICT-2007.1.2, p11. [18] Romulus Consortium. Service and software architectures, infrastructures and engineering.romulus - domain driven design and mashup oriented development, 2009. Disponible en http://www.ict-romulus.eu/. [19] D. P. Templates. Herramienta dwoo, 2009. Disponible en http://dwoo.org/. [20] E. Templating. Herramienta evoque templating, 2009. Disponible en http://evoque.gizmojo.org/. [21] I. The java Comunity Process (SM) Program: Alex Buckley, Sun Microsystems. Jsr 175: A metadata facility for the javatm programming language, 2009. Disponible en http://www.jcp.org/en/jsr/detail?id=175. [22] J. van Bergen. Velocity or freemarker?, 2009. Disponible en http://www.javaworld.com/javaworld/jw-11-2007/jw-11-java-templateengines.html?page=3. [23] Wikipedia. Entrada template engine (web), 2009. Disponible en http://en.wikipedia.org/wiki/Template engine (web).