Charting

...

1. Use a single, uniform data-source
2. Use a clear structural description of how the chart is composed.
3. Avoid redundancy, but not at the cost of usability.
4. Separate data, structure and style.
   #

Regarding JFreeChart

Although JFreeChart is a good starting point to collect features for the chart-engine, it is definitely no sane base to build a clean structural guide on how a chart is composed or styled. Therefore I will not tie the engine to the JFreeChart architecture.

...

(11/15) We are not specifically looking to contribute back the abstract API layer and JFreeChart wrapper implementation back to the JFreeChart project. We are under the assumption that Dave wouldn't want it anyway. We will however cotribute back sensible changes to the JFreeChart API.

High-Level Requirements

• The engine must be able to produce charts for Reports (Graphics2D), the Web (Raster-Images, AJAX, Flash?) and must be able to transform the Pentaho-Chart-Definitions into 3rd Party Chart-Engine definitions (OpenOffice-Charts, maybe Excel)
• The charts must be able to create HyperLinks and/or output-target specific Event-Handlers (for AJAX)
• The chart engine must have a minimal set of dependencies. It must not depend on the Pentaho-Plattform, so that JFreeReport-users who dont use the Plattform are able to use it freely.
• The chart engine must provide extension points so that it can be integrated seamlessly into the Reporting Engine and the Plattform.
• The engine must provide users the option to use their own target-specific datasources (for real-time charts).

Architectural Draft

Data-Source Definition

After carefully analyzing the JFreeChart data-source implementations, it is safe to say: All chart-data sources can be expressed using one or more tables. Each data-item can be treated as a compound-key to compound-value mapping. All additional JFreeChart-datasource constraints can be derived from the given data using one or more simple data-preprocessing steps.

...

In this spirit, we are considering an XML metadata definition that can be used by the chart engine to determine the dimensionality, column\row inclusions\exclusions, position for data retrieval, etc. The metadata layer at some point could come from the Pentaho metadata layer (Note that the engine won't know nor care about the origin of the metadata).

Structural Definition

The structural definition will be represented in XML, and only deal with the nuts and bolts of the chart:

...

This representation tells you nothing of styles or data or metadata, but only the layout and functional description of the elements listed above.

Style Definition

The first consideration for the style definition is a CSS based architecture, where we define CSS styles that represent the style changes that could typically be applied to any of the chart elements. We are not limited to the W3C's style attributes (although we should use them where appropriate, for familiarity), but can define our own chart specific style attributes. It will be the chart engine's duty to know how to apply a given style to a given structural element.

...