jasper_reports NG

Just després del llançament del primer release candidate de Koo, hem incorporat un conjunt de canvis interessants al mòdul jasper_reports. Aquests canvis es poden classificar en dues àrees: rendiment i localització.

Rendiment

En l’àrea de rendiment, hem creat un procés Java —que s’inicia automàticament quan s’executa el primer informe— que permet evitar el cost d’iniciar la màquina virtual de Java cada vegada que cal imprimir un informe. L’altra millora de rendiment només afecta els informes que utilitzen la interfície XML, que poden beneficiar-se d’un augment de velocitat de fins al 10% gràcies a l’ús de fitxers CSV en lloc d’XML. És totalment compatible i no canvia res quan l’usuari crea informes nous.

Localització

Si les millores de rendiment són una bona notícia, la part de localització és la meva preferida. Ara és possible utilitzar camps traduïbles, com ara el nom del producte o el nom del país, en qualsevol idioma.

Per defecte, la interfície XML crearà els camps traduïbles en l’idioma de l’usuari que executa l’informe, però si, quan s’afegeix el camp a iReport, se li assigna el tipus java.lang.Object en lloc de java.lang.String, es pot utilitzar la sintaxi següent a l’informe:

$F{product_name}.get( "ca_ES" )

A més, si l’informe és, per exemple, una factura, tindrà una relació amb el tercer. En aquest cas es pot utilitzar:

$F{product_name}.get( $F{partner_language} )

Si la traducció no està disponible per a aquell idioma, s’utilitzarà la traducció per defecte.

Però no ens vam aturar aquí amb les millores de localització i vam decidir ampliar les funcionalitats de localització de JasperReports.

Dit senzillament, el mecanisme de traducció dels informes Jasper és deficient. Se suposa que cal utilitzar un paquet Java (fitxer .properties) per idioma i fer servir $R{key} a les expressions, i evidentment no admet funcionalitats disponibles en qualsevol sistema de traducció modern, com ara els paràmetres i les formes plurals.

El funcionament del nostre mecanisme per al dissenyador d’informes és força senzill: allà on calgui traduir alguna cosa es pot utilitzar:

tr("This is the text I want to translate")

O bé:

tr("{0} out of {1} think this translation system is great!", $F{positive},$F{total})

També es poden utilitzar formes plurals:

trn("One person", "{0} people", $F{people})

De fet, s’han implementat gairebé totes les funcions de java gettext. Però això no era suficient, i per a totes també n’hem implementat una versió amb la configuració regional parametrizable. Per tant, es pot utilitzar:

tr( new Locale("ca", "ES"), "This text will be translated into Catalan even if the default report locale is in german!")

Quan vam aconseguir que això funcionés, necessitàvem una manera d’extreure aquests textos i ho vam fer molt senzill. Al directori jasper_reports/java hi ha un parell d’scripts:

• jrxml2pot: extreu els textos de l’informe a un fitxer .pot, que es pot traduir fàcilment amb qualsevol eina estàndard o fins i tot amb Launchpad.
• po2properties: converteix el fitxer PO traduït en un fitxer .properties.

El directori de l’informe hauria d’acabar contenint els fitxers següents:

text superreport.jrxml superreport_ca_ES.properties superreport_de_DE.properties ...

Si una traducció no està disponible, s’imprimirà el text original.

Tot això és molt fàcil de fer i, el que és més important, es pot integrar als vostres mòduls i traduir mitjançant Launchpad. L’inconvenient d’aquest mecanisme és que, a causa de la manca d’infraestructura de JasperReports per fer aquest tipus de tasques, vam haver de tornar a implementar el GroovyCompiler, i va néixer I18nGroovyCompiler. Això significa bàsicament que:

• Cal utilitzar Groovy com a llenguatge de l’informe.
• No es pot previsualitzar l’informe dins d’iReport.

Actualització: proves recents han demostrat que alguns informes triguen menys de la meitat del temps que trigaven amb el dorsal XML; per tant, segons l’informe, els guanys de rendiment són realment importants.