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.
We finally reached the age of full interactivity.