We have recently added a new feature to jasper_reports module that allows users to have access to fields structure from iReport, avoiding the need of creating the XML file. Note that although the module works with both v5 and v6 this feature will only be available in v6.

Using this functionality is really easy. Simply install latest version of jasper_reports module and in iReport create a new Remote XML file datasource. And in XML URL specify OpenERP's XML-RPC URL and append "/jasper/" and the internal name of the model we want to use (in the example "purchase.order"). After that we can add several paramaters, but all of them are optional, because they can be specified in openerp's server configuration file and they also have default values.  Here's a list of parameters available:

Recently jasper_reports integration module received another improvement. We added a specific menu entry in "Administration" -> "Customization" -> "Jasper Reports" -> "Jasper Reports" and it looks like this:





The screen is much more user friendly that the Low Level -> "XML Report" and allows selecting the model as well as directly uploading the reports. It has also been enhanced with respect to recent versions in that it's no longer necessary to press the "Update from attachments" button and users can upload multiple subreports.



With recent changes we feel the next steps we should carry on to improve integration is adding a new Fields Provider class to iReport and allow connecting to OpenObject directly. This would allow:

• An entry called "openobject" in iReport which makes it easier for users to remember (instead of telling them to use "XPath")
• Compiling and previewing reports with translations (Using our tr() family of functions)
• Previewing reports with real data
• Viewing Field names in user's language (as currently) but without the real field name concatenated
• Browsing to a depth higher than five levels, which is currently almost impossible.
• Avoid the need of creating an XML file with OpenObject client before designing (or redesigning) a report

The only implemented feature of all this is the first one:





This, however, is not very interesting as it simply shows the XML fields provider. So it just avoids making it a bit odd for the user having to select XPath.



The rest of the features are not very hard to implement but require some hours of work we can't currently affort to finance alone. However, if you think you can contribute with code or money we can make it happen faster and they're advantatges that will save quite some time of work to all of us once implemented.



So if you're interested you can contact us at "info at nan dash tic dot com" or contact with me directly at "albert at nan dash tic dot com".

Right after the release of the first release candidate of Koo, we've commited a bunch of exciting changes in the jasper_reports module. Those changes can be classified in two separate areas: performance and localization.



Performance



In the performance area, we've created a java process (which is started automatically when the first report is executed) that allows avoiding the overhead of starting up the Java Virtual Machine each time a report has to be printed. The other performance improvement affects only those reports using the XML interface, which can benefit from up to 10% speedup thanks to the use of CSV files instead of XML. It is totally compatible and doesn't change anything when the user creates new reports.



Localization



If performance improvements are good news, the localization part of this post is my favorite one. Now it's possible to use translatable fields such as product name, country name, etc. In any language you want.



By default, the XML interface will create translatable fields in the same language of the user that is executing the report, but if when the field is added in iReport, you set it to type 'java.lang.Object' instead of 'java.lang.String' you can use the following syntax in the report:



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



Even more, if the report is an invoice, for example, it will have a relation to the partner. In this case you can use:



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



If the translation is not available for that language, the default one will be used.



But we didn't stop localization improvements here and decided to enhance JasperReports localization features.



Put simply, jasper reports translation mechanism sucks. You're supposed to use a java bundle (.properties file) per language and use $R{key} in the expressions everywhere and obviously doesn't support features available in any modern translation system such as parameters and plural forms.



How does our mechanism work for the report designer? Pretty simple, anywhere you need to translate something you can use:



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

or

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

or you can use plural forms:

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



In fact, almost all functions in java gettext are implemented. But that wasn't enough, and for all of them we implemented one with configurable locale. So you can use:



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



Once we got this working we needed a way to extract those texts and we've made it incredibly simple. There are a couple of scripts in the jasper_reports/java directory:



jrxml2pot: Which extracts the texts from the report into a .pot file, easily translatable with any standard tool or even launchpad!

po2properties: Which converts the translated po file into a .properties file.



We should end up with the following files in our report directory:



superreport.jrxml

superreport_ca_ES.properties

superreport_de_DE.properties

...



If a translation isn't available the original text will be printed.



All this is very easy to do, and most importantly, it can be integrated in your modules and translated using launchpad! The drawback of this mechanism is that, due to lack of infrastructure in JasperReports to do this kind of stuff, we had to reimplement the GroovyCompiler and I18nGroovyCompiler was born. This basically means that:

• You must use groovy as language in your report. That's not much of a problem, as it's possibly the best choice anyway.
• You can't do a preview of the report inside iReport. This is a more annoying problem. It isn't hard to solve, but let's leave it to most enthusiastic java programmers that read the planet and see if somebody volunteers for that ;-)

Update: Recent tests have shown that some reports take less than half of the time they used with XML backend, so depending on the report performance gains are really important.