Monthly Archives: June 2009

No need to look sour: We’ll show how Citrus came to the Pentaho-Report-Designer

On Wednesday 3PM London time (or 10AM Orlando time) we will give a Community Web-Ex about how Reporting Changes in the upcoming Citrus-Release.

Aside from officially announcing the switch from our well-loved, most-hated-by-sales “0.8.x” version numbering schema, we will shed some light what new features we have and on how the new features will make your reporting life easier. During the first part, we will give an short overview about the new stuff (and the reasons behind it) and also explain the changed relationship of the new reporting engine and the BI-Platform. As we all know, that there is no other truth than working code, the second part will demonstrate how to utilize parameters, the new datasources and the Rich-Text engine (along with the magic wizard), to build a simple interactive ad-hoc reporting solution. Building this solution should be fast, so we’ll have plenty of time for questions and answers at the end of the Web-Ex.

The web-ex information will be available via the Pentaho-Forum.

Scripted data-sources: And yet another usecase for XActions gone

On the holy quest to cut back on the usage of XActions for everydays life, we come a lot closer to the goal now.

XActions are cool for solving the more complex cases of BI-Tasks. But for just getting the data for a friggin’ report they are the literal hammer trying to squash the mosquito. Yes, it works, but it leaves a mess behind. (Sorry, Marc, I tried to love XActions, but it felt like making love to a cactus. I just cant stand programming in XML for ordinary daily tasks.)

So we now have the Scriptable-Datasource working. The datasource itself was working since months in the engine, but as I learned the hard way: No feature is used when there is no GUI. And since last week the UI for defining those datasources is working. The scriptable datasource uses Apache’s Bean-Scripting-Framework to let you instantiate Swing TableModels during the report processing. The datasource has access to the current DataRow (the thing that holds the data for the current report-state), and thus is fully parametrizable. At the same time, you are free to pull in any third party code (like code that accesses your backend systems or instantiates EJBs) so that you are no longer limited to plain databases or precompiled JARs (via the Java-Call datafactory) to get your data in. And the best of all: Assuming that you have the right set of libraries on the classpath, you can use a large set of scripting languages to get your job done.

Nothing would be perfect without an example, right? So here we go:

import javax.swing.table.DefaultTableModel;

String[] columnNames = new String[5];
columnNames[0] = "Year";
columnNames[1] = "Q1";
columnNames[2] = "Q2";
columnNames[3] = "Q3";
columnNames[4] = "Q4";

DefaultTableModel model = new DefaultTableModel(columnNames, 3);
model.addRow(new Object[]{ new Integer(2001), new Integer(10), new Integer(10), new Integer(14), new Integer(21)});
model.addRow(new Object[]{ new Integer(2002), new Integer(14), new Integer(34), new Integer(10), new Integer(12)});
model.addRow(new Object[]{ new Integer(2003), new Integer(10), new Integer(11), new Integer(14), new Integer(15)});
return model;

And now back to the drawing board, as I still have to get the attribute-expression support for the “query”, “query-timeout” and “query-limit” attributes back in place. At that point, you will be able to compute the query that used for the report. But that’s definitely a topic for another blog entry.

Real Rich-Text support is making it’s way into the engine

One of the last commited items out of my infinite bag of things to add to the reporting system was the support for real Rich-Text content. (PRE-166)

Rich-Text basically means: Formatted text. But although formatted text may be nice, our layouting system easily can do a bit more than that. As the current layout-system of the classic-engine is a spin-off of the layout system of the frozen Flow-Engine, we can render full-featured documents at nearly no additional costs. And of course, implementing a minimalistic system that supports little more than , ,

    is boring. If I wanted an non-challenging job, I would become Banker, or even Central-Banker.

    Today, surprisingly after only 6 hours of work, the first RTF document appeared happily in the report-designer’s report-preview. And even more surprising to me: There are only two features missing to make it totally complete: Justified text-alignment and line-indentions. Solving the justified-text-alignment problem is a to large to solve within the Citrus timeframe (at least if I want to have it safe and scalable. Text-processing is the stuff that takes ages to compute and eats memory like trolls eat children). But text-indention is easy to bring in (it’s yet another “almost there” feature).

    Now how does it work?

    Rich-Text processing is disabled by default and has to be enabled by setting the “rich-text-type” attribute to the desired document type. This way we preserve backward compatiblity (as old reports have no such setting, so they default to text/plain documents) and performance (as plain-text does not need to go through the Rich-Text parser). If the rich-text-flag is set, any content that could contain a document (CLOB, BLOB, char- and byte-arrays and InputStreams and Readers, and of course javax.swing.text.Document instances) are passed into the layouter as raw-objects. The layout-preprocessor then translates these objects into real Document instances by calling RichTextProcessor implementations. These implemenations are pluggable, so that you can easily bring your own rich-text format into the engine. The built-in RichTextProcessors use the Swing-EditorKit parsers for RTF and HTML to create the Documents and then translate these documents into Bands, Label and Content-(formerly known as Image)-elements.

    The original element is then treated as Band and the generated Band/Elements are processed as if they were childs of this artifical band.

    Of course, introducing artificial Bands and Elements did have side-effects. Not on the engine’s core, which did not required a single change. But we now have a new Element-Type called “external-element-field”, which allows to use the same trick outside of the layouter. If the element returns a “org.pentaho.reporting.engine.classic.engine.core.Element” instance, that instance is printed as if the element was a band and the returned instance were the band’s only child. So far, the only one real use for it is to load external Sub-Reports from an URL or path, but after Citrus we may weave some more magic in this area.

    If you haven’t checked out our Citrus-Reporting yet, then you are missing an amazing new world. So don’t hesitate and grab the latest build!