Knowledge Base (Display) Knowledge Base (Display)

Release notes 0.9.3

 The release notes will be progressively completed

Preferences user interface

  • The toolbar options that can be enabled / disabled in the preferences mode are now displayed in a more compact manner, such shown in the screen below.

Pixel perfect

  • To avoid some nasty html visual effects wich sometimes occur, the reportlet fragment is now displayed once the javascript objects are fully initialized (this initialization lasts about 100ms)
  • The overlay shadow is now perfectly centered in the reportlet window when a report is being generated, and the small space between the borders and the report has been removed:

Report browser issue on Gatein / JBoss EPP

In 0.9.2 the ajax report browser has an issue on gatein and jboss EPP. In these portals, when a user is switching between the view mode an the edit mode, unlike on most portals the page is not completely refreshed. It disrupts a little bit the jquery jsTree plugin, which is used to manage the report browser. If you open this browser in view mode, and then switch to edit and open the browser again then the folders cannot be collapsed, until you refresh the page. It is fixed in 0.9.3

uPortal compatibility

The compatibility and the css have been improved,  the reportlet is now very pleasant to use in uPortal. However there is still an issue with the styles generated by the birt engine, especially on tables and cross-tables. For more informations please refer to the uPortal install article in the knowledge base.

jQuery conflicts

  • The jQuery framework is used by the reportlet to handle the client-side user interface. Since this framework is very powerful and popular, it may be used on a same page by other components, or by the portal itself (such uPortal and Liferay 5). And of course  these components can require a different jQuery release. For example the reportlet uses jQuery 1.7 when Liferay 5 uses jQuery 1.2.
  • In v0.9.2, the jQuery.noConflict() method is invoked at the end of the reportlet javascript. This method is not sufficient when there are different jQuery versions
  • To fix once and for all the issues related to the jQuery conflicts, in 0.9.3 the reportlet now uses a private jQuery instance, named 'visiojQuery'. That means unless one of your component (or the portal) includes jQuery too, the '$' and 'jQuery' variables are not available anymore in the reportlet scope.
If you already modified some customizable reportlet JSP pages, you must check if the jQuery variable is used inside. When it is, you should replace it by this new instance name.

For example, in the sample extended toolbar JSP, in 0.9.2:        

jQuery('#<portlet:namespace/>__toolbar_custom1').button({ icons: {primary: "ui-icon-signal-diag"},  text: false  });    

has been replaced in 0.9.3 by:          

visiojQuery('#<portlet:namespace/>__toolbar_custom1').button({ icons: {primary: "ui-icon-signal-diag"},  text: false });

jQuery CSS conflicts

Note to avoid any CSS conflict with other components, the reportlet uses a CSS selector (see the jQuery themeroller documentation for more informations). Thus, your jQuery UI components should not be disturbed by the reportlet styles. Have a look at the 'interface theming'  demo section: with a css selector, each reportlet has its own theme and absolutely not disrupts the others. However it does not work in the other way: if an external component uses jQuery UI without a CSS selector, it may  break some reportlet styles, especially if it is based on a different jQuery UI release.

Drillthrough preferences

In 0.9.2, the drillthrough window height could not be customized because of a bug. It is fixed in 0.9.3, you can now for example use a tiny drill window such below if it is necessary for one of your reports. Of course, this set up can be different for each reportlet window, like any other preference.

The drill ajax animated gif has undergone a facelift, it is now bigger. You can customize it by replacing the related image with your favorite one.

Liferay 5.x compatibility 

The v0.9.2  works with Liferay 6.x (the live demo is currently on 6.1.GA1), but fails on Liferay 5.x. There are many issues:

  1. liferay-plugin-package.xml does not include the 5.1 and 5.2 versions, which prevents the reportlet to be deployed and even blacklists it
  2. the jstl taglib framework causes a null exception in the JSP page when an expression language is used
  3. the javascript type is not always set, wich prevents liferay 5 to minify the scripts and triggers an exception
  4. there are jQuery core & plugins conflicts between the portal and the reportlet 
  5. the reportlet currently requires a 1.6 or later JVM, when the Liferay 5.x are bundled by default with a 1.5.x JVM. If you run the reportlet with a 1.5.x JVM, then a 'UnsupportedClassVersionError' is thrown. 
  6. there are css conflicts between the portal and the reportlet

The issues 1,2,3,4 are fixed in 0.9.3, and you can fix the issue 5 by upgrading the portal JVM. The final result is very beautiful, and some minor bugs wich happen in Liferay 6 don't exist in this version.

For the css conflicts, since Liferay 5 does not use any css selector for jQuery, it is difficult to find a completely satisfactory solution. The principal issue was the report browser, it was completely broken by Liferay's theme and could not be used. The v0.9.3 css has been modified to protect the key properties of this browser. Although most css issues have been resolved, as you can see on the screen below the theme is a small mix between the Liferay 5 theme and the reportlet theme. You can of course harmonize it by using the jQuery themeroller, and building a theme wich corresponds to your portal. An article has been added in the knowledge base to explain how to embed your own theme.

Liferay configuration

  • In the default Liferay configuration, the reportlet is now maximized when a user switches to the help mode (see the contextual help section in the live demo). You can control this behaviour in the liferay-portlet.xml file.
  • In v0.9.2, in some contexts the liferay portlet options (preferences, help, refresh...) cannot be accessed when we click on. It is fixed in 0.9.3 In v0.9.2,
  • when a reportlet is minified by an authenticated user, and the page is refreshed, then the reportlet window cannot be restored until it is maximized. It is fixed in 0.9.3. 

Note the liferay-portlet.xml option <render-weight> causes several such issues and should not be used anymore, until it is fixed by the Liferay team.

Reportlet actions URL security

  • The 0.9.2 release has implemented a security/exception model for the reportlet ajax resource URL. In 0.9.3 it is extended to the action URL as well. An action URL is used when a user:
  1. Selects  a new report with the browser in the preferences mode
  2. Selects some new default parameters values with the parameters dialog in the preferences mode
  3. Clicks on "Apply" or "Cancel" in the preferences mode

When the reportlet must process one of these actions, it now checks if the reportlet window is really in 'preferences mode' (also often called 'edit mode') or not. This prevents any kind of hacking from malicious users, who could try to workaround the portal security by building their own action URL.

  • The only action wich is not concerned is the 'Publish event'. This action can be used in the extended toolbar to send informations to the other portlets on the page  (see the inter-portlet communication demo section). Since this action is designed to be used in a very generic purpose, it is difficult to decide in the reportlet if the user is really authorized  or not to trigger it.

So, if the process involved by this event is sensitive in your project, it is the responsability of the consumer portlet to check the user role when this event is received.

Cache management

  • In 0.9.2, the cache manager is created with a random name, for example: net.sf.ehcache.CacheManager@4397d6c7. This may be a problem to use the JMX operations programmatically, if you want to apply operations to the visioneo caches in your own application. It is fixed in 0.9.3, a constant name is now set to ehcache: visioneo.reportlet.cachemanager. It can also be accessed in a public constant: VisioCacheManager.CACHE_MANAGER_NAME.


  •  When the engine is stopped, in some context the application server throws a 'ClassNotFoundException' for the class is fixed in 0.9.3. .


Code optimization

  • The code is progressively enhanced  and optimized throughout the beta phase, to make it as efficient and maintainable as possible.




Tags: release notes
Average (0 Votes)
Most Recent
Release notes v3.2 24 November 2015
Release notes v3.1 26 September 2015
Release notes v2.2 19 August 2015
Release notes v1.4.1 06 December 2013
Release notes v1.4.0 03 December 2013
Release notes v1.3.0 13 October 2013
Release notes v2.0 26 September 2013
Release notes v2.1 01 August 2013