Purifying action: Report-Designer 2.0 is on the way

Tue, 29 Jul 2008 20:45:00 GMT

Three weeks! It now has been three weeks since the purification started. Three weeks of furious deleting, refactoring, screaming, crying, contemplating suicide, restructuring, analyzing and finally fixing the report-designer's codebase.

Are we finished now? Not yet. The current SVN version is now in a state where all the major parts are in place, but the overall experience is still .. experimental.

My development theme for the new report-designer is "back to the roots". Almost all external dependencies are gone now. Well, some minor dependencies are still waiting for their extermination:

JGoodies Formlayout - a creature spawned in the depths of the seventh circle of hell - is still used in many of the old dialogs. As this layout manager is as hard to maintain as the infamous Gridbag-Layout of the core JDK, there are no advantages of using it. Whenever we now touch one of the old dialogs, we will replace this nightmare with a plain Gridbag-Layout. GridbagLayout may be ugly, but at least we don't have to ship a Jar for it or force other developers to learn yet another useless trick.
IntelliJ IDEAs NotNull-annotations. The idea of marking parameters, fields and return-values as nullable seems to be a good idea at first. But sadly, the implementation of said idea is horrible. When using IntelliJ, violations of the annotation constraints easily remain undetected - the compiler does not warn you and so you won't see errors until you get the Exception at runtime. In addition, anyone not using IntelliJ wont have much use of these annotations anyway. Therefore, for the new code and all classes touched during the redesign: Let's kill these annotations. Now we replace them with strict coding guidelines. We start with explict checks on all public or protected methods, wherever we do pass object-references around. On a architecture level we prevent NullPointerExceptions by having a strict object-model with strict type-checks. And of course, this includes that we do not pass private collections around, as it seems all so common these days.
DOM4J and Jaxen: These classes are used by the Pentaho-Version-Checker to parse a structurally simple XML document. One could use a combined total of 500KB of libraries or one could use down-to-earth XML-parser implementations that use JDK-1.5 functionality only. Guess what the old code does and guess with what we will end up with.

Very early in the game, we already removed the Pentaho-Platform, as using a ?? MB collection of libraries to read a single properties-file was a bit ridiculous. We removed all magical code-generation (that was done via asm-lib and reflection) as all of these uses were easily replaceable by a single well-defined interface. We removed the PullParser and all the XML-magic as XML parsing in JDK 1.5 is really well-defined (heck, it was well defined in the age of JDK 1.2, for the usecases we need here). We removed SWT as I cant stand libraries that crash the Virtual Machine just because they cannot cope with the processor architecture or operating system. I still believe in the "100% pure Java" world Sun advertised ages ago. And we removed Castor, as a OR-mappers used for parsing a non-complex XML file is a WTF on its own.

Inside the code itself, we sliced through the event handling and created a clear event-dispatching path. Although it must be fun to virtually connect every object with every other object, I do not want to spend the few remaining years of my sanity on maintaining such a beast. Almost all cases of invoking methods by reflection were removed by simply creating interfaces containing the method to be called. But that road was no fun to walk - so at the end we ripped out the old data-model and rendering and editors and ... and so the new report-designer works directly against the reporting-engine's datastructures and with components that follow a strict separation of concerns.

And now, with all magic killed, we leave the dark age and enter the age of enlightening. With a sane and maintainable architecture to start with, we will finally be able to spend less time on maintenance and more time on developing new features. After all, bug-hunting is not a fun activity, so spending less time there leaves us more time for the fun stuff.

The new report-designer data-model is a thin wrapper around the visual objects of the reporting-engine. The model itself only provides some caching of the layout, change tracking and event-notification and nothing else. There is no point in wrapping around datasources or functions, as long as we set the social rule that after these objects have been altered we always notify the model of it.

The report-designer's code now no longer contains copies of existing reporting-engine functionality. Datasources, layouting, expressions - it all comes from the one and only principal source now.

And the result of all of this: The report-designer now automatically provides access to all features of the reporting engine as soon as the reporting engine implements them. We can now guarantee that whatever the report-designer shows you in the edit view will be the same result the reporting engine will show you. Everything the reporting-engine can do, can now be done with the report-designer.

We now also started to define the first set of plugin-points for the report-designer, so that anyone can hook-in own editors, datasources and actions without dealing with all the complexity of the whole project.

Independence Day

Sun, 06 Jul 2008 14:06:00 GMT

While the former colonies celebrated their successful rebellion to evade British taxes on tea and other goods, I created my own Declaration of Independence (from old and obsolete rules that burden the pioneer spirit and now just exist for historical reasons).

As the name suggests, the "extensions-reportdesigner-parser" project is a Classic-Engine extension that allows the engine to use *.report files as produced by the current Report-Designer as ordinary report-definition files.

On the quick-win side, this immediately removes the need to convert reports into the extended-XML format during the publish process. As long term gain, this module acts as a compatibility layer as soon as we start the report-designer redesign.

There are several reasons why it is a good idea to separate the report-definition fileformat from the internal model representation:

The report-designer's XML file references classnames and therefore makes it hard to do refactorings without affecting the names put in there. Now we can start to move classes and functionality around without having to worry how our actions may break existing reports.
The report-designer's internal model is a incomplete (and in some cases incompatible) copy of the reporting-engine's report-model. This results in subtle bugs and diverging feature sets, which in return leads to frustration and ugly hacks.
As the designer maintains a own copy of the reporting-engine's model, changes in the reporting engine's processing (notably new features or extensions of existing features) need a long time until they become available in the designer.
And of course: Maintaining a own model is expensive. The time we have to spend to keep the models in sync, is time we cannot spend to make the designer better.

This module now is the living proof, that there is no need for a separate report-designer model and therefore no need to have a *.report format in the future.

With 0.8.11, we can safely map everything that is inside the report-designer's file format into the native elements of the reporting-engine. The charting in the designer is covered by the legacy-charting sub-project, the design-time properties in the *.report-files (like the horizontal and vertical rulers) are mapped into Element-attributes, and for each data-set offered by the designer, we have a sane equivalent. (And in case the dataset-specification itself was a bit insane in itself, as it happens with the XML-datasources, we now have legacy-projects for these parts as well. No matter how strange the code or behavior is, for the sake of full backward compatibility we'll keep that code alive.)

During the next two weeks, we will concentrate on making the Report-Designer 2.0 ready for a bright future. At the end, we will end up with a designer that is a natural extension of the reporting engine core. In the process to that glorious goal, we will happily remove the code that simply duplicates the engine's behavior. Add a bit of reducing information redundancy and let us reduce the magic of reflection to a minimum and we shall be in a good shape for the next years to come.

Reporting Tales - report-designer tag

Purifying action: Report-Designer 2.0 is on the way

Independence Day