Eat your own dog-food ..

One of the most effective ways to force developers to create sane code and usable programs, is to force them to use the results of their own work by themselves. Almost immediately non-critical but very annoying bugs get fixed and at least the UI gets cleaned up.

And right now I’m swallowing hard on my bad-tasting dog-food.

With release 0.8.8 of the Classic Engine of Pentaho-Reporting we’ve added Master-Detail reporting capabilities to the reporting engine. It looked very sane at the beginning with unmatched flexibility in the parameter and query passing, and a clean design. The whole beast was bug-infested like a dead dog in the middle of the road on a hot summer day. So we went through the usual cycle of fixing the implementation flaws (and we still do).

But very soon we hit the wall, where we never would have expected it: in the Page headers and page footer handling. Page header and footer are special sections that live outside the normal content flow. Those tricky beasts can appear everywhere and they really don’t care about grouping structures or the general report layout. There are several ways to deal with that problem. Accutate’s BIRT solved it by making the page headers static; page headers that cannot contain data from the normal flow are a little bit dull, but they are easy to implement, they are predictable. Pentaho Reporting and JasperReports have chosen to do it the hard way. Here page header and footers can contain data from the current report. Sure, it doesn’t sound that complicated at first; it’s just printing data after all. But suddenly, as the contents (and thus the height) of the page-header and footers becomes dynamic, you have created some feedback loops in your report processing.

With master-detail reports, that thing becomes even worse. Suddenly the detail report has the ability to define its own page-header or footer. While this is ok sometimes, there are equally important cases where one wants to preserve the master-report’s header all the time. And we haven’t even thought about repeating group-header or footer (which behave like additional page-header or footer, but are only printed as long as the group is active).

As a result, we’ve introduced ‘sticky’ flags for all of these header and footer sections. Once a band is marked ‘sticky’, it will be printed on all detail reports. If the detail report adds its own header or footer, these new sections will be printed below the master’s sticky sections.

But the really funny thing is: Before starting the task of ‘Adding the master-detail capabilities’ we had a lot more planning than for every other addition to that development branch of the reporting engine. And still: We did not realize that such things could happen unless we got hit by them. Praise the OpenSource model where users immediately send you a friendly flame for messing up. Praise the fast release cycles, where one month later the flaw get fixed or at least improved (which gives more friendly flaming until everyone is satisfied).

Damn I really love flaming. Like a good steak, just the right amount of flames makes a raw piece of meat (or software) a well-tasting experience.

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.