Unified Fileformat Fallout: Report Element Attributes

One of the few classes that has not changed much since ages is the “Element” class. The element defines the smallest building block of a report definition. Elements carry style-information and data. If the element is a band, it carries no data but other elements instead.

The data-source system of the Elements that was used to compute and transform raw-data into presentable data was always a weak part of our system. The system was organized as a set of filters that could be composed together to form a transformation chain. While this bought us great flexiblity, we paid for this with a nearly unmanageable object structure that was hard to manage at run- and designtime.

With the addition of the unified fileformat and with a strong carry over of ideas from the hibernating Flow-Engine, the classic-engine finally leaves this old system behind.

Elements now carry attributes and a thing called ElementType. The ElementType uses the current state and the element’s attributes to compute the presentation value. Under the hood, there not much magic going on anymore: The new code simply copies and pastes the old data-source code and transfers the parameters of the old datasource-classes into the element’s attribute set.

What a small change, but what a huge effect.

The ElementType is now a simple, immutable class. No expensive cloning is needed at runtime. All of the sudden, all of the element’s parameters are well-defined and accessible for the design-time tools.

Now that everything in an element is either part of the style-information or part of the attribute-collection, we can fire up the magic bag of dirty tricks. Style-expressions are used to compute style-information at runtime. Now, with attributes in a similiar structure, attribute-expressions do the same for the attributes.

But thats not all: The attribute-collection is not limited to the data-processing at all. We can store anything in there, and so we do.

Every element can now carry raw HTML fragments and bits of JavaScript that are inserted into the produced HTML output. Web-Applications can and will make use of this feature to bind the generated reports closer to the generating web-application. Elements carry Excel-Page-Header and Page-Footer strings which can be embedded into the Excel output. The Swing-Preview-Components look out for special attributes on all elements to create Hyperlinks and Clickable areas. Applications embedding the report engine can transport any data through the report into the print-preview to create their own Drill-Through systems.

We finally reached the age of full interactivity.

This entry was posted in Development on by .
Thomas

About Thomas

After working as all-hands guy and lead developer on Pentaho Reporting for over an decade, I have learned a thing or two about report generation, layouting and general BI practices. I have witnessed the remarkable growth of Pentaho Reporting from a small niche product to a enterprise class Business Intelligence product. This blog documents my own perspective on Pentaho Reporting's development process and our our steps towards upcoming releases.