var sMapping = reportContext.getHttpServletRequest.getRequestURI();
var nPos = sMapping.lastIndexOf( "/" ) + 1;
this.text = sMapping.substring( nPos );


You can place the above code inside a label to see the servlet mapping.

• New and Notable for BIRT 3.7 Release
• BIRT 3.7.0 Download Page
• BIRT Project Plan

The main difference is we will use the method getAllParameters() instead of getParameters() of ReportDesignHandle. It seems that getParameters returns only the “top level” parameters, whereas getAllParameters flattens the groups and the nested as well as top level parameters. One thing to watch out for is that the return types of the two functions are different: java.util.List (getAllParameters) vs. org.eclipse.birt.report.model.api.SlotHandle (getParameters). Also, we have included a check for the class of the parameter entry in the list, in order to exclude the groups themselves. You can comment out the if statement in case you wish to see the group names as well.

Here is the updated working code:


var sOutput = "";
var parameterArray = reportContext.getDesignHandle().getAllParameters();
var parameterCount = parameterArray.size();
for( var i = 0; i < parameterCount; i++ )
{
  var sParClass = parameterArray.get( i ).getClass().toString();
  if( sParClass == "class org.eclipse.birt.report.model.api.ScalarParameterHandle" )
  {
    var sParName = parameterArray.get( i ).getFullName();
    var sParVal = reportContext.getParameterValue( sParName );
    sOutput = sOutput + sParName + " = " + sParVal + "\n";
  }
}
this.content = sOutput;


Each chart has a palette. The palette determines the colours used for drawing the series in the chart. From the UI perspective, the palette options are accessed on the last tab of the Edit Chart dialog (Format Chart), the first selection in the tree on left-hand-side (Series). It is worth noting that a chart only has one palette, even if the chart contains multiple series.

By default there are 32 entries in the palette. They are used in the chart from top to bottom, i.e. in the default scenario the first category will be coloured blue, the next one red and so on. The Add and Remove buttons in the Series Palette dialog can be used to change the number of entries. What happens when the chart contains more categories than the list of palette entries? The answer is that the palette will wrap around, i.e. the 33rd category will be coloured in the same way as the first one. If the number of categories is known in advance, one can extend the palette using the Add button to create the necessary number of palette entries. (Naturally, one should question the design of such a chart, will the user really be able to extract any meaning from a chart with 32 or more different colours? In most cases, probably not.)

Each palette entry itself can be edited. Not only is it possible to set one of the predefined colours, one can also set a custom colour, a linear gradient based on two colours or even an image file. It is also possible to specify different colour for positive and negative values.

As we already mentioned, the palette colours are applied top to bottom without any further logic, in particular they are not tied to the actual data point values themselves. Several common scenarios and scripting approaches for solving the issue have already been discussed on this blog: Setting BIRT chart series palette dynamically, Setting BIRT chart series palette dynamically, part 2 – area charts, Setting BIRT chart series palette dynamically, part 3 – stacked bar charts.

In the second part of this article we will look at how the palette and related objects can be manipulated programmatically, i.e. through scripting.

• BIRT versus Jasper
• BIRT versus Pentaho
• OSS Reporting Comparison Matrix

The traditional way of accessing BIRT report parameters from script is through the expression ReportContext.getParameterValue( parameterName ). Naturally this method requires one to know the name of the parameter at design time (i.e. when writing the script), which is fine in most cases.

There are however situations in which a more generic approach is preferable. For example, one might wish to implement a usage statistics system, where each time a report is run certain information is persisted in a usage tracking database. This will include the name of the report, the time of execution and perhaps also the selected parameter values. The obvious difficulty is that different reports are likely to have different sets of parameters. In anything but the simplest and smallest set of reports, it would be impractical to edit the code individually for each report. On the contrary, the appropriate approach is to create a generic library component which can be maintained in one place and referenced from the reports.

The code below is a simple demonstration how the list of parameters and their values can be read dynamically at run-time. To see it working, simply paste it into the onPrepare method of a text element.


var sOutput = "";
var parameterArray = reportContext.getDesignHandle().getParameters();
var paramaterCount = parameterArray.getCount();
for( var i = 0; i < paramaterCount; i++ )
{
  var sParName = parameterArray.get( i ).getFullName();
  var sParVal = reportContext.getParameterValue( sParName );
  sOutput = sOutput + sParName + " = " + sParVal + "\n";
}
this.content = sOutput;


reportContext.getReportRunnable().getReportName();

Two points to note:

• The expression actually returns the full report URI rather than just the name, i.e. something like file:/C:/BIRT/Report01.rptdesign.
• The URI is percent-encoded and so space characters will be returned as %20 and so on for other special characters, e.g. file:/C:/Program%20Files/Apache%20Software%20Foundation/Tomcat%205.5/webapps/birt-viewer/Report01.rptdesign.

Once again, let’s start with a quick recap. In what is a fairly common scenario, one chooses the palette colours to match with particular category values. For example, in the chart below “High” is represented in green, “Mid” in orange and “Low” in red.

However, if for a particular dataset one of the of category values is not present, the palette colours are still used in the same order, meaning the “Mid” area is now shown as red and “High” as orange. This is confusing for the end user:

As in the previous examples, we solve this problem by adding a little bit of script to override the chart’s default behaviour.


function beforeDrawDataPoint( dph, fill, icsc )
{
  var sValue = dph.getSeriesDisplayValue();
  // set( R, G, B, alpha )
  if( sValue == "1-Low" )
  {
    fill.set( 242, 88, 106, 255 );
  }
  else if( sValue == "2-Mid" )
  {
    fill.set( 232, 172, 57, 255 );
  }
  else if( sValue == "3-High" )
  {
    fill.set( 128, 255, 128, 255 );
  }
}


We also need to override the beforeDrawLegendItem method, so that colours in the legend match the chart colours.


function beforeDrawLegendItem( lerh, bounds, icsc )
{
  var sValue = lerh.getLabel().getCaption().getValue();
  var fill = lerh.getFill();
  // set( R, G, B, alpha )
  if( sValue == "1-Low" )
  {
    fill.set( 242, 88, 106, 255 );
  }
  else if( sValue == "2-Mid" )
  {
    fill.set( 232, 172, 57, 255 );
  }
  else if( sValue == "3-High" )
  {
    fill.set( 128, 255, 128, 255 );
  }
}


The palette colours are now assigned dynamically based on actual category values. The rendered chart looks as shown below, independent of the colours selected in Chart Wizard and their order.

Often there is one particular grouping (series) which is especially important and we want to draw the report viewer’s attention to it by showing the labels for that series only. This cannot be achieved through the Chart Wizard UI but can be done with a bit of scripting.

The method which needs to be overriden is beforeDrawSeries. In this example, series labels will be shown for the “1-Low” series and hidden for the other ones.


function beforeDrawSeries( series, isr, icsc )
{
  // get class of the renderer
  var type = isr.getClass().toString();
  // check for area chart renderer
  if( type == "class org.eclipse.birt.chart.render.Area" )
  {
    var val = isr.getSeriesRenderingHints().getDataPoints()[0].getSeriesDisplayValue();
    if( val == "1-Low" )
    {
      series.getLabel().setVisible( true );
    }
    else
    {
      series.getLabel().setVisible( false );
    }
  }
}


The result looks as follows:

]]> http://www.martinhammer.com/blog/index.php/2010/09/selectively-hiding-series-labels-in-birt-area-chart/feed/ 0 http://www.martinhammer.com/blog/index.php/2010/08/keeping-track-of-scripts-in-birt-reports/ http://www.martinhammer.com/blog/index.php/2010/08/keeping-track-of-scripts-in-birt-reports/#comments Tue, 03 Aug 2010 14:21:38 +0000 martin http://www.martinhammer.com/blog/?p=523 The ability to add custom scripts to report elements is a very powerful feature of BIRT. It allows the report developer to modify or override the default behaviour of the element; this blog features many examples of when this might be useful. However, as the number of scripts in a report increases, the report becomes harder and harder to maintain.

The Layout view or the Property Editor window do not indicate whether and what scripts exist on a particular element, and so it would seem the only way to check is to select the element and switch to the Script tab and look through the methods. Of course this would be incredibly tedious and impractical in a complex report.

Luckily, the Outline fast view has a Scripts item tucked away at the bottom of the list. When expanded, this shows all items in the report which contain custom scripts (expanding the item shows the overridden methods). Right-click brings up an option to go to the report element in the report Layout, and thus actually figure out which item it is referring to.

The deeper lesson is that one should use scripts only when necessary and if there is no other way to implement the required functionality. And of course thorough documentation also helps with maintenance…