Blog de Antonio Manuel Muñiz

Desarrollo, Ingeniería y Calidad del Software

Análisis de un proyecto web Java y Javascript en Sonar

Actualmente existen plugins de Sonar para analizar código Javascript en Sonar, pero hay una limitación, y es que los proyectos en Sonar tienen un lenguaje determinado, por ejemplo, no podemos analizar un proyecto Java y Javascript al mismo tiempo. La única solución (hasta que Sonar permita el análisis de proyectos multi-lenguaje) es crear dos proyectos en Sonar usando el concepto de branch, y configurando dos análisis, uno para el código Java y otro para el código Javascript.

Si el proyecto está modelado con Maven podemos hacer uso de perfiles para definir las dos tareas. Para ello crearemos el siguiente perfil (suponiendo que el código Javascript se encuentre en src/main/webapp/ui):

<profile>
    <id>js</id>
    <build>
        <plugins>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>build-helper-maven-plugin</artifactId>
                <executions>
                    <execution>
                        <phase>process-resources</phase>
                        <goals>
                            <goal>add-source</goal>
                        </goals>
                        <configuration>
                            <sources>
                                <source>src/main/webapp/ui</source>
                            </sources>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</profile>

Y lanzaremos dos análisis en Sonar, uno para analizar el código Java:

mvn clean install sonar:sonar -Dsonar.branch=Java

Y otro para analizar el código Javascript:

mvn clean install sonar:sonar -Pjs -Dsonar.branch=Javascript -Dsonar.language=js -Dsonar.dynamicAnalysis=false

Previamente es necesario instalar el plugin de análisis de código Javascript en Sonar (es cuestión de minutos usando el update center). El resultado serán dos proyectos en Sonar. Lo ideal sería un sólo proyecto, pero hasta que Sonar soporte proyectos multi-lenguaje es la única solución.

En la instancia de Clinker que usamos en klicap puedes ver un ejemplo de proyecto Javascript en Sonar.

Carga lo que necesitas y cuando lo necesitas con Ext.Loader

Cuando se usa ExtJS en aplicaciones relativamente grandes se tiende a tener una gran cantidad de ficheros javascript, la descarga de todos esos ficheros puede suponer un lastre muy importante durante la inicialización de la aplicación. Hasta ahora en klicap hemos usado la solución tradicional, que durante mucho tiempo ha sido el uso de compresión y ofuscado (minify), pero ExtJS 4 ofrece otra posibilidad, el uso de un cargador (Ext.Loader) que descarga los ficheros javascript necesarios en el momento necesario.

Para usar Ext.Loader es necesario seguir algunas normas y convenciones, que por otro lado vienen bien para que el proyecto esté ordenado. El primer paso es incluir sólamente el core de ExtJS, lo cual supone el primer beneficio, en lugar de 1,1MB (ext-all.js) sólo hay que descargar 175KB (ext.js):

<head>
    <script type="text/javascript" src="ext/ext-debug.js"></script>
</head>

 

Ext.Loader.setPath({
    'MyApp': 'ui/app'
});

Esta configuración indica al loader que las clases con namespace MyApp debe buscarlas en ui/app. Por ejemplo, la clase MyApp.view.User debe estar contenida en el fichero ui/app/view/User.js.

El uso de Ext.Loader implica la separación de clases en ficheros independientes, práctica muy común en otros lenguajes de programación, pero no obligatoria en Javascript.
El resultado (y el objetivo) de Ext.Loader es que el fichero User.js sea descargado y evaluado sólo cuando sea necesario, es decir, cuando se llame a Ext.create(‘MyApp.view.User’).

En este sentido hay dos opciones, el uso de requires o no en la definición de las clases Javascript:

Ext.define('MyApp.view.User', {
    extend: 'Ext.panel.Panel',
    requires: [
        'MyApp.view.UsersGrid'
    ],
    initComponent: function() {
        var grid = Ext.create('MyApp.view.UsersGrid');
        ...
        this.callParent(arguments);
    }
});

En este caso, la carga de MyApp.view.UsersGrid (fichero ui/app/view/UsersGrid.js) se realizará en el momento de la definición de la clase MyApp.view.User, por tanto la descarga de UsersGrid.js se producirá siempre que se cargue User.js. Si se elimina el uso de requires, la carga de UsersGrid.js se realizará en el momento en que se llame a initComponent en User, es decir, cuando se llame a Ext.create(‘MyApp.view.User’), si esta llamada no se produce entonces nunca se descargará UsersGrid.js.

ComboBox en Sencha ExtJS 4. Carga asíncrona

La clase  Ext.form.field.ComboBox en ExtJS es realmente potente, permitiendo desde paginación hasta la posibilidad de definir mediante Ext.XTemplate el contenido de cada línea del combo. Pero su comportamiento asíncrono puede convertirse en un problema cuando la conexión con el lado del servidor es lenta. En klicap usamos ExtJS desde hace casi dos años, y nos hemos encontrado con este comportamiento recurrentemente, ya era hora de solucionarlo :-)

Para situarnos. Todo componente de ExtJS que actúa como contenedor de datos tiene asociado un Store (Ext.data.Store) el cual define una serie de parámetros que afectan a la relación entre el contenedor y los datos:

  • Estructura de datos. Haciendo uso de Ext.data.Model (se establece una relación entre la fuente de datos y los objetos javascript que los mapean).
  • Características de la fuente. La fuente de datos puede encontrarse en memoria (un array que contiene los datos) o puede ser remota (lo cual implica el uso de AJAX). En este último caso se ha de definir el formato de los datos recibidos (JSON o XML).
  • Comportamiento. Se indica si el Store se cargará automáticamente al crear el objeto, o requiere una llamada a load().

Un ejemplo de definición de un combo (de timezone) con fuente de datos remota, JSON y carga automática (el combo se encuentra dentro de un formulario y este asu vez dentro de una ventana):

Ext.define('User', {
    extend: 'Ext.window.Window',
    initComponent: function() {
        this.items = [{
            xtype: 'form',
            border: false,
            fieldDefaults: {
                labelWidth: 100
            },
            items: [{
                xtype: 'fieldset',
                anchor: '100%',
                title: 'User data',
                items: [{
                    layout: 'anchor',
                    items: [{
                        xtype: 'combo',
                        fieldLabel: 'Timezone',
                        name: 'timezone',
                        width: 300,
                        queryMode: 'local',
                        triggerAction: 'all',
                        valueField: 'id',
                        displayField: 'timezone'
                        store: Ext.create('Ext.data.Store', {
                            model: 'Timezone',
                            proxy: {
                                type: 'ajax',
                                url: 'api/timezone',
                                reader: {
                                    type: 'json',
                                    root: 'timezones'
                                }
                            },
                            autoLoad: true
                        })
                    }]
                }]
            }]
        }];
        this.callParent(arguments);
    },
    modal: true,
    width: 430,
    height: 350,
    layout: 'fit',
    title: 'User'
});

Durante el proceso de carga de datos en el formulario ExtJS hace el mapping de los valores que vienen en el JSON en los campos del formulario (usando la propiedad name del campo). Por tanto la carga del formulario sería tan simple como:

var userForm = Ext.create('User');
userForm.getComponent(0).getForm().load({
    url: 'api/user/12',
    method: 'GET',
    success: function (form, action) {
        userForm.show();
    }
});

En este fragmento de código se realizarán dos peticiones HTTP GET al servidor: una para la carga de combo (GET ‘/api/timezone’ debido a la propiedad autoload: true del combo) y otra para la carga de los datos del usuario (GET ‘/api/user/12′).

Como he comentado antes ExtJS realiza llamadas internas a Ext.form.field.Base.setValue() para setear el valor de cada campo del formulario (como parte de la llamada a load). Pero ¿qué sucede cuando se intenta setear el valor del combo antes de que el listado de valores haya sido cargado?, es decir, la llamada a ‘/api/user/12′ termina antes que ‘/api/timezone’. El resultado es que el valor no se fija y el combo se queda vacío, y eso es un #FAIL.

Para evitarlo es necesario esperar a que la carga del listado de valores de combo haya terminado y sólo despues hacer el setValue(). La siguiente extensión se encarga precisamente de esto de una forma bastante simple:

Ext.define('AsyncSafeComboBox', {
    extend: 'Ext.form.field.ComboBox',
    alias: 'widget.safecombo',
    setValue: function(value, doSelect) {
        if(this.store.loading){
            this.store.on('load', Ext.bind(this.setValue, this, arguments));
            return;
        }
        this.callParent(arguments);
    }
});

La clave está en la propiedad ‘loading’ de Ext.data.Store que indica si el store asociado al combo está aún cargando sus datos. Si la llamada a setValue se realiza durante la carga del store, entonces se retrasa hasta que el store indique que ya ha acabado (evento ‘load’).

Sólo habría que cambiar el xtype de nuestro combo a ‘safecombo’ y siempre se realizará la carga de forma correcta.

Migración de ExtJS 3 a ExtJS 4

En klicap estamos llevando a cabo la migración de uno de nuestros productos (Opina 2, aún en desarrollo) a ExtJS 4. He creido oportuno compartir aquí algunas notas sobre la migración.

Uso de Ext.define y Ext.create

En ExtJS 4 las clases se definen con Ext.define y se crean instancias con Ext.create, lo cual sustituye a Ext.extend y new en ExtJS 3

ExtJS 3:

Ext.namespace('Opina.view');
Opina.view.TextQuestion = Ext.extend(Ext.grid.GridPanel, {
    initComponent: function() {
        ...
        Opina.view.TextQuestion.superclass.initComponent.call(this);
    }
});
Ext.reg('textquestion', Opina.view.TextQuestion);

ExtJS 4:

Ext.define('Opina.view.TextQuestion', {
    extend: 'Ext.grid.Panel',
    alias: 'widget.textquestion',
    initComponent : function() {
        ....
        this.callParent(arguments);
    }
});

Este fragmento de código está lleno de detalles:

  • Uso de Ext.define y el parámetro extend
  • Nueva nomenclatura, Ext.grid.GridPanel pasa a ser Ext.grid.Panel (regla extensible a todo el framework)
  • Nueva función callParent presente en todos los componentes
  • Definición automática de xtype usando alias

2. Uso de Ext.data.Model y Ext.data.Store
En ExtJS 4 se ha separado por completo el concepto de almacén de datos (Store) y definición de estructura de datos (Model). Lo que era un Store con una serie de campos (fields) ahora es un Store asociado a un modelo:

Ext.define('Opina.model.TextQuestion', {
    extend: 'Ext.data.Model',
    fields: [
       { name: 'elementSetId' },
       { name: 'elementType' },
       { name: 'freeTextLabel' },
       { name: 'helpMessage' },
       { name: 'id' },
       { name: 'position' },
       { name: 'questionType' },
       { name: 'surveyId' },
       { name: 'template' },
       { name: 'wording' },
       { name: 'multiplelines', mapping: 'data.multipleLines' },
       { name: 'validations' }
    ]
});
var store = Ext.create('Ext.data.Store', {
    model: 'Opina.model.TextQuestion',
    proxy: {
        type: 'ajax',
        reader: {
            type: 'json',
            root: 'question'
        }
    }
});

3. Mejora de formularios

El layout “form” ha desaparecido. En ExtJS 3 si querías un campo de texto con un label (muy común) la única opción era que el campo estuviera dentro de un panel con layout “form”. En ExtJS 4 cualquier layout puede acojer un campo con label, lo cual flexibiliza mucho la definición de formularios y evita el uso de paneles sin sentido que sólo contienen un campo.

4. Métodos up y down

ExtJS 4 proporciona dos métodos que facilitan la recuperación de elementos en un contenedor, sus hijos y ancestros. En ExtJS 3 se suele usar “find”, pero down es más versátil al permitir el uso de expresiones de búsqueda complejas, por ejemplo “#” para buscar por “itemId”.

var store = myWindow.down('#options-grid').getStore()

El funcionamiento de “up” es igual pero aplica a ancestros. Realmente útil.

5. Mejoras en Grids

Los grids han sufrido cambios importantes, sobre todo en lo relacionado a eventos. En ExtJS 4 los grids son un DataView más, por tanto cada fila es un item y se trata como tal. No existen los eventos del tipo “rowdblclick” sino “itemdblclick”.

6. Organización

Esto no está directamente relacionado con la migración, pero el nuevo enfoque MVC de ExtJS hace que de forma natural tu proyecto esté mejor organizado. Nosotros hemos organizado el proyecto así:

7. Firefox + Firebug son tus amigos

Durante el proceso de migración ha sido fundamental el uso del binomio Firefox + Firebug. Sin estas herramientas la migración es un infierno.
Sencha proporciona un adaptador especial para la migración, que relaiza una traslación de ExtJS 3 a ExtJS 4 de ciertas propiedades, nombre de clases, paquetes y métodos. De esta forma podemos ir realizando la migración gradualmente y solucionando las incompatibilidades que son logeadas en la consola de Firebug.

8. Otros detalles
Dejo en el tintero muchos detalles de menor importancia, como cambios de nombre en métodos (que no son detectados por el pack de migración) como “reload()” en Ext.grid.Panel, que deja de existir estando disponible sólo “load”, o el objeto resultado de un submit cuya respuesta viene en “action.result.data” y no en “action.reader.jsonData”.

9. Sigo echándolo en falta
Sigo echando el falta un mecanismo que controle la carga asíncrona de un ComboBox, que tantos problemas da cuando la conexión es lenta (se hace el setValue antes de que los valores del combo hayan sido cargados). Paro solventar esto en @klicap hemos desarrollado una pequeña extensión, pero eso lo contaré en otro post ;-)

Y pasó Apache Barcamp Spain 2011

Es la primera vez que participo en la organización de un evento como Apache Barcamp Spain 2011, así que como es de suponer todo ha sido nuevo para mí. Desde el primer día en que Manuel Recena (@recena) me dijo que había estado hablando con Carlos Sánchez (@csanchez) sobre la posibilidad de organizar algo en Sevilla en torno a Apache, hasta el último minuto en el patio de La Carbonería no he parado de aprender, y por supuesto, de disfrutar. Disfrutar viendo como llega la gente por la mañana a la ETSII, como se presentan más de 25 charlas, y aunque no pude asistir a ninguna completa (es lo que tiene la organización) si que pude ver algunos “minutos” de charlas muy interesantes.

Pero sí, es cierto, participar en la organización de un evento así es duro, y en klicap lo hemos hecho. Hay que trabajar para que salga algo decente, hay que trabajar bastante, y aún así se cometen errores. Ya hemos tenido feedback del evento, tanto de lo bueno como de lo malo, así que ya sabemos algunos de esos errores. De todo se aprende… esa es la idea. Pero cuando un asistente se acerca y te dice que lo está pasando genial, o cataloga el evento de “Eventazo”, entonces se te olvidan estos detalles “menos buenos” y piensas -el año que viene me tiro al pozo de nuevo- Así que eso haré, tirarme al pozo :-)

Gracias a todos, de verdad, a asistentes y patrocinadores, por hacer que el evento haya estado a la altura. Gracias.