Pentaho ChartBeans

Owned by Former user (Deleted)
Last updated: Apr 24, 2009 by Former user (Deleted)Version comment
3 min read

This documentation is under construction. Some portions may be obsolete/inaccurate.

Charting

At the moment, the charting capabilities of the reporting engine are strongly underdeveloped. The ChartExpressions can be safely considered a usability nightmare (but to quote Marc: "..., but it works.").

The following draft-specs are based on an analysis of JFreeChart, but can be applied to other chart-engines as well. The chart-engine reuses a couple of ideas that have been originally developed for the reporting engine.

  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 should be able to replace the JFreeChart engine as the engine underlying our chart API at any time.

(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.

(11/15) The statements above describe the simple, generic case. we also must have the ability to process any additional metadata that the user may be able to provide about their data, so that subsets and subsections of the dataset can be used in the chart without the user having to restructure their query/data. We (Kurtis and Gretchen) will provide use cases for directing the structuring and feature capabilities of the metadata.

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:

  • the chart area
  • the plot area
  • the axes
  • the legend
  • the series
  • not complete, just a place to start.

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.

Thomas mentioned he already has an abstracted CSS parser in the classic report engine that we will be able to use.