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.