Chapter 13. Understanding the BIRT APIs
The Eclipse BIRT code consists of many hundreds of Java classes and interfaces, but most of them are private, for use by contributors to the BIRT open source project. Developers of applications use the classes and interfaces that are in the public API. The public API consists of the classes and interfaces in the following package hierarchies:
• Report Engine API
The org.eclipse.birt.report.engine.api package hierarchy contains the API that a developer of a custom report generator uses. This API provides the most commonly used functionality for a reporting application. The key class in the Report Engine API is ReportEngine. This class provides access to all the tasks that create a report from a report design or a report document. The Report Engine API also includes the classes and packages that support the scripting capabilities of a report design.
• Design Engine API
The org.eclipse.birt.report.model.api package hierarchy is by far the larger of the two reporting APIs. This API provides access to the content and structure of a report design, a template, or a library. A reporting application can call this API to change the structure of a design. The Design Engine API is also the API that a developer of a custom report designer uses.
• Chart Engine API
The org.eclipse.birt.chart package hierarchy contains the API that a developer of a custom chart generator uses. A reporting application can also use this API in conjuction with the Report Engine and Design Engine APIs to create and modify chart elements in a report design.
BIRT provides a set of extension APIs for creating custom report items, custom data sources and data sets, custom rendering formats, and custom charts. Part 5, “Working with the Extension Framework” provides detailed examples of how to use these extensions.
For detailed information about API classes and interfaces, see the Javadoc in the online help in BIRT Programmer Reference→Reference→API Reference and BIRT Charting Programmer Reference→Reference→API Reference.
Package hierarchy diagrams
This chapter contains hierarchical diagrams for the packages in the BIRT APIs. These diagrams show the hierarchy of the classes in the package and interfaces local to the package or implemented by classes in the package. Classes and interfaces preceded by a package name are not local to the package. In these hierarchical diagrams, the graphics shown in Table 13-1 indicate different attributes and relationships of the classes and interfaces.
Table 13-1 Conventions for the hierarchy diagrams
About the BIRT Report Engine API
The BIRT Report Engine supports report generation and rendering in several different environments, such as:
• Stand-alone engine
A Java developer uses a stand-alone engine to render a BIRT report from an existing report design (.rptdesign) file. In this environment, the Java developer creates a command line application to write a complete report in any of the supported formats.
• BIRT report viewer
BIRT Report Designer uses the BIRT report viewer to view a report as paginated HTML. The BIRT report viewer is a web application that runs in the Tomcat Application Server, which is embedded in Eclipse. This viewer contains an embedded report engine.
• Custom report designer with an embedded engine A custom desktop reporting application integrates the BIRT Report Engine for the purpose of previewing the report.
• Web application that embeds the engine A web application similar to the BIRT report viewer can use the BIRT Report Engine to generate a web-based report.
The BIRT Report Engine supports running and rendering reports in these diverse environments. It does not perform environment-dependent processing such as URL construction, image storage, and design file caching. The application using the engine API must provide such context information to the engine.
The BIRT Report Engine API consists of interfaces and implementation classes that support integrating the run-time part of BIRT into an application. The API provides task classes that support the following operations:
• Discovering the set of parameters defined for a report
• Getting the default values for parameters
• Running a report design to produce an unformatted report document
• Running a report design or report document to produce any of the supported output formats
• Extracting data from a report document
Creating the BIRT ReportEngine instance
Each application, whether it is stand-alone or web-based, only needs to create one ReportEngine instance. As the BIRT Report Engine is thread-safe, the single-instance recommendation is not a restriction.
Use an IReportEngineFactory instance and an EngineConfig object to create the ReportEngine instance.
Using the BIRT Report Engine API
The BIRT Report Engine API supports the following key tasks to generate reports:
• Setting options for the report engine using an EngineConfig object
• Starting the Platform
• Creating a ReportEngine object using the ReportEngineFactory
• Opening an existing report design using one of the openReportDesign( ) methods of ReportEngine or opening an existing report document using the openReportDocument( ) method
• Optionally, obtaining design details of the report parameters using an IGetParameterDefinitionTask object
• Running and rendering a report using IRunAndRenderTask or IRunTask followed by IRenderTask
• Cleaning up the report engine by calling destroy( ) on the engine instance to unload extensions and delete temporary files
A few key classes and interfaces provide the core functionality of the BIRT Report Engine. The following sections provide an overview of these classes.
EngineConfig class
The EngineConfig class wraps configuration settings for a report engine. Use the EngineConfig object to set global options for the environment of the report engine, including:
• Specifying the BIRT home, the location of the engine plug-ins and Java archive (.jar) files
• Setting OSGi arguments
• Setting the Platform context
• Setting resource locations
• Adding application-wide scriptable objects
• Setting the directory where the report engine writes temporary files
• Managing logging
ReportEngine class
The ReportEngine class represents the BIRT Report Engine. To instantiate the ReportEngine object, use a factory method that takes an EngineConfig object as an argument. If the configuration object is null, the environment must provide a BIRT_HOME variable that specifies the BIRT home. Use a ReportEngine object to perform the following tasks:
• Getting the configuration object
• Opening a report design or a report document
• Creating an engine task to get parameter definitions
• Creating an engine task to access the data from a report item
• Getting supported report formats and MIME types
• Creating an engine task to run a report or render a report to an output format
• Creating an engine task to extract data from a report document
• Changing the logging configuration
• Cleaning up and destroying the engine
IReportRunnable interface
To use the engine to work with the report design, load the design using one of the openReportDesign( ) methods in the ReportEngine class. These methods return an IReportRunnable instance that represents the engine’s view of the report design. Use an IReportRunnable object to perform the following tasks:
• Getting standard report design properties such as the report title
• Getting any images embedded within the report design
• Getting a handle to the report design
IReportDocument interface
To use a report document, load the document using one of the ReportEngine. openReportDocument( ) method. These methods return an IReportDocument instance. Use an IRenderTask object to render the report specified by an IReportDocument object to a supported output format. Use table of contents markers in the IReportDocument to determine pages to render. The IReportDocument interface also supports retrieving page counts, parameter values used while creating the report document, and bookmarks.
IEngineTask interface
The IEngineTask interface provides the framework for the tasks that the report engine performs. The IEngineTask interface manages the scripting context, getting and setting parameter values, setting the report’s locale, getting the current status of a task, and cancelling a task. The other task interfaces extend IEngineTask.
IGetParameterDefinitionTask interface
The IGetParameterDefinitionTask interface extends IEngineTask to provide access to information about parameters. Use the engine factory method to create an IGetParameterDefinitionTask object takes an IReportRunnable argument. Parameter definitions provide access to:
• Information that BIRT Report Designer specified at design time
• Static or dynamic selection lists
• User-supplied values
• Grouping structure of the parameters
• Custom XML
• User-defined properties
IDataExtractionTask interface
The IDataExtractionTask interface extends IEngineTask to provide access to the data stored in an IReportDocument object. Use an IDataExtractionTask object to examine the metadata for a set of data rows. Use the metadata to select a set of columns to extract, sort, or filter. This interface can extract the data from:
• The whole report document
• A single report item
• A single instance of a report item
IRunTask interface
The IRunTask interface provides the methods to run a report design. This task saves the result as a report document (.rptdocument) file on disk. An IRunTask object takes parameter values as a HashMap. Call the validateParameters( ) method to validate the parameter values before running the report.
IRenderTask interface
The IRenderTask interface provides the methods to render a report document to one of the supported output formats. This task can save the report to a file on disk or to a stream.
Use the RenderOption class to set options for rendering. Set options specific to particular output formats using subclasses of the RenderOption class. Pass the appropriate render option object to the IRenderTask object before rendering the report.
IRunAndRenderTask interface
The IRunAndRenderTask interface provides the methods to run a report and render it in one of the supported output formats. This task can save the report to disk or to a stream. This task does not create an intermediate report document (.rptdocument) file.
An IRunAndRenderTask object takes parameter values as a HashMap or individually. Call the validateParameters( ) method to validate the parameter values before running the report.
An IRunAndRenderTask object supports setting the same rendering options as an IRenderTask object. Pass the appropriate render option object to the IRunAndRenderTask object before running the report.
Report engine class hierarchy
The class hierarchy in Figure 13-1 illustrates the organization of the classes in the report engine package. Unless otherwise specified, all classes and interfaces in this diagram are in the org.eclipse.birt.report.engine.api package.
Figure 13-1 Classes within the report engine package
Report engine interface hierarchy
Figure 13-2 contains the interface hierarchy for the Report Engine API. Unless otherwise specified, all interfaces in this diagram are in the org.eclipse.birt.report.engine.api package.
Figure 13-2 Interface hierarchy for the report engine package
About the Design Engine API
The Design Engine API is also known as the report model API. The Design Engine API is the API that a tool writer uses to develop a design tool. The Design Engine API supports creating, accessing, and validating a report design, library, or template.
The org.eclipse.birt.report.model.api package contains the interfaces and classes used to access the design model objects. The Design Engine API supports the following tasks:
• Reading and writing design files
• Maintaining the command history for undo and redo
• Providing a rich semantic representation of the report design
• Providing metadata about the ROM
• Performing property value validation
• Notifying the application when the model changes
Using the BIRT Design Engine API
The purpose of the BIRT Design Engine API is to modify or create a design file that the BIRT report engine can use to generate a report. BIRT Report Designer, for example, uses the BIRT Design Engine API for this purpose. A custom report design tool, written for the same general purpose as BIRT Report Designer, can also use the BIRT Design Engine API to generate a design file. The Design Engine API supports libraries and templates in the same way as report designs. The BIRT Design Engine API does not include any user interface classes. A custom report design tool must provide its own user interface code.
The design engine supports the following tasks to create or modify a BIRT report design:
• Setting options for the design engine by using a DesignConfig object
• Starting the Platform, if not already started
• Creating a DesignEngine object using the DesignEngineFactory
• Beginning a user session by using the DesignEngine.newSessionHandle( ) method to instantiate a SessionHandle object
• Setting session parameters and loading the property definitions of the report elements by using the SessionHandle object to create an instance of the ReportDesignHandle class
• Using the ReportDesignHandle to create an ElementFactory, which can create report elements
• Using the ReportDesignHandle to add new elements to the report design or modify existing elements
• Saving the report design file by using the ReportDesignHandle
The following sections describe the primary classes of the BIRT Design Engine API.
DesignConfig class
The DesignConfig class wraps configuration settings for a design engine. Use a DesignConfig object to set global options for the design engine, including:
• Specifying the location of engine plug-ins and Java archive (.jar) files
• Setting the Platform Context
• Specifying configuration variable
• Set OSGi arguments
DesignEngine class
The DesignEngine class represents the BIRT design engine. Create the DesignEngine with a factory method that takes a DesignConfig object. If the configuration object is null, the environment must provide the path to the BIRT home, the directory that contains the engine plug-ins and JAR files. The DesignEngine class is the gateway to creating the other objects needed to build a report design tool. Use the methods of the DesignEngine class to create a locale-specific SessionHandle object by calling the newSession( ) method. The SessionHandle provides access to report design objects.
SessionHandle class
The SessionHandle class represents the user session. A SessionHandle object provides access to the set of open designs. A session has a set of default values for style properties and a default unit of measure. The session also has methods to create and open report designs, templates, and libraries, as well as setting the path and algorithm used to locate resources. The methods to create or open a report design return a ReportDesignHandle object.
ModuleHandle class
ModuleHandle provides access to the common structure and functionality of report designs, templates, and libraries. The ModuleHandle class is the parent class of the ReportDesignHandle and LibraryHandle classes. ModuleHandle provides access to the generic properties, such as author and comments. Use ModuleHandle for many tasks on the file, including:
• Saving the module to a file
• Accessing the command stack for undo and redo
• Navigating to the various parts of the module
• Retrieving the module location
• Getting configuration variables
Other ModuleHandle methods support getting handles to the individual report items and all the other elements in a report design, template, or library. These elements and supporting components include:
• Report items. These elements are visual report elements such as tables, grids, images, and text elements.
• Code modules. These modules are global scripts that apply to the file as a whole.
• Parameters.
• Data sources, data sets, and cubes.
• Color Palette. This component is a set of custom color names.
• CSS files that the module uses.
• Theme. The theme is a group of styles that the module uses for formatting report elements.
• Master page. This element defines the layout of pages in paginated report output.
• Libraries. Any module can use one or more libraries to provide predefined elements.
• Resources. External files, for example, providing images or lists of messages in localized forms.
• Embedded images.
ReportDesignHandle class
ReportDesignHandle provides access to report design-specific properties such as the scripts that execute when generating or rendering a report. This class also provides access to properties that templates use, such as the cheat sheet, display name, and icon file.
ReportDesignHandle is a subclass of ModuleHandle, so supports all that class’s functionality. Use ReportDesignHandle to get handles to individual report items and for many report design-specific tasks, including:
• Navigating to the various parts of the design
• Setting the event-specific scripts that execute when the report engine runs and renders the report
The ReportDesignHandle also has methods to gain access to the following report components:
• Styles, the list of user-defined styles for formatting report elements
• Base directory, the location of file system resources with relative paths
• Body, a list of the report sections and report items in the design
• Scratch Pad, a temporary place to hold report items while restructuring a report
LibraryHandle class
LibraryHandle is a subclass of ModuleHandle, so supports all that class’s functionality. LibraryHandle also provides access to the following library-specific properties:
• Name space, the name that a module including a library uses to identify the elements that the library defines
• The set of themes that the library defines
• Imported CSS styles used by themes
DesignElementHandle class
DesignElementHandle is the base class for all report elements, both visual report item elements and non-visual ones, such as data sets and cubes. DesignElementHandle provides generic services for all elements, such as:
• Adding a report item to a slot
• Registering a change event listener
• Getting and setting properties, names, and styles
• Getting available choices for specific properties
• Dropping an element from the design
• Copying, pasting, and moving report items
Individual element handle classes
Element handle classes derive from ReportElementHandle. Each report element has its own handle class. To work with operations unique to a given report element, cast the ReportElementHandle to the appropriate subclass for the element. For example, the CellHandle class provides methods such as getColumn( ), and the DataSourceHandle class has methods such as setBeforeOpen( ).
Design engine class hierarchy
Figure 13-3 illustrates the hierarchy of the classes within the design engine package. Unless otherwise specified, all classes and interfaces in this diagram are in the org.eclipse.birt.report.model.api package.
Figure 13-3 Classes within the report model package
DesignElementHandle hierarchy
Figure 13-4 contains the class hierarchy for DesignElementHandle in the org.eclipse.birt.report.model.api package and the classes that derive from it.
Figure 13-4 DesignElementHandle class hierarchy
ReportElementHandle hierarchy
Figure 13-5 contains the class hierarchy for ReportElementHandle in the org.eclipse.birt.report.model.api package and the classes that derive from it. The interfaces that the classes implement are all in the org.eclipse.birt.report .model.elements.interfaces and org.eclipse.birt.report.model.elements packages. Classes with names that have a prefix of olap are in the org.eclipse.birt.report.model.olap package.
Figure 13-5 ReportElementHandle class hierarchy
ReportItemHandle hierarchy
Figure 13-6 contains the class hierarchy for ReportItemHandle in the org.eclipse.birt.report.model.api package and the classes that derive from it. The interfaces that the classes implement are all in the org.eclipse.birt.report.model.elements.interfaces and org.eclipse.birt.report.model.elements packages.
Figure 13-6 ReportItemHandle class hierarchy
ElementDetailHandle hierarchy
Figure 13-7 contains the class hierarchy for ElementDetailHandle in the org.eclipse.birt.report.model.api package and the classes that derive from it.
Figure 13-7 ElementDetailHandle class hierarchy
StructureHandle hierarchy
Figure 13-8 contains the class hierarchy for StructureHandle in the org.eclipse.birt.report.model.api package and the classes that derive from it.
Figure 13-8 StructureHandle class hierarchy
Design engine interface hierarchy
Figure 13-9 contains the interface hierarchy for the Design Engine API. All interfaces in this diagram is in the org.eclipse.birt.report.model.api package
Figure 13-9 Interface hierarchy for design engine package
About the BIRT Chart Engine API
The chart engine API uses the Eclipse Modeling Framework (EMF) as a structured data model. Use the classes and interfaces in the chart engine API to modify chart objects within a BIRT reporting application or in a stand-alone charting application.
The Chart Engine API includes many packages in the org.eclipse.birt.chart hierarchy. The model.* packages contain the core chart model interfaces and enumeration classes generated using EMF. The model.*.impl packages contain the core chart model implementation classes generated using EMF. All other packages are dependencies from and indirect references to the core model. There is a one-to-one correspondence between classes in the impl packages and interfaces in matching model packages. The classes in the impl packages implement the methods in the interfaces of the model classes. The impl classes also contain factory methods used to create an instance of a class.
Using the BIRT Chart Engine API
Although there are over 500 classes and interfaces in the BIRT Chart Engine API, most functionality for creating or modifying a chart is concentrated in a small subset of classes and interfaces. The primary interface in the BIRT Chart Engine API is the Chart interface. An object of the Chart type is called the chart instance object. The Chart interface has two subinterfaces, ChartWithAxes and ChartWithoutAxes. DialChart is a third interface that inherits from ChartWithoutAxes. ChartWithoutAxes defines a pie chart and DialChart defines a meter chart. ChartWithAxes defines all other chart types.
To create a chart instance object, call create( ) in ChartWithAxesImpl, ChartWithoutAxesImpl, or DialChartImp, as in the following statement:
ChartWithAxes myChart = ChartWithAxesImpl.create( );
To set the basic properties of a chart, such as its orientation and dimensionality, use setter methods of the Chart interface, such as:
myChart.setOrientation( Orientation.VERTICAL_LITERAL );
myChart.setDimension( ChartDimension.THREE_DIMENSIONAL );
Set more complex properties of a chart, like characteristics of the chart’s axes and series by getting an instance of the object to modify and then setting its properties. For example, to set an x-axis caption, use the following code:
Axis xAxis = myChart.getPrimaryBaseAxes( )[0];
xAxis.getTitle( ).getCaption( ).setValue( "Months" );
Although charts are often identified by type, such as a pie chart or a line chart, a chart with multiple series of differing types cannot be classified as one type. A series has a specific type. Use the BIRT Chart Engine API to create a specific type of series by using the create( ) method of one of the SeriesImpl subclasses. For example, the following code creates a bar series:
BarSeries barSeries1 = ( BarSeries ) BarSeriesImpl.create( );
Chart engine class hierarchy
The diagrams that follow contain hierarchies for the following chart engine packages:
• org.eclipse.birt.chart.aggregate
• org.eclipse.birt.chart.model.attribute
• org.eclipse.birt.chart.datafeed
• org.eclipse.birt.chart.model.component
• org.eclipse.birt.chart.device
• org.eclipse.birt.chart.model.data
• org.eclipse.birt.chart.event
• org.eclipse.birt.chart.model.layout
• org.eclipse.birt.chart.exception
• org.eclipse.birt.chart.model.type
• org.eclipse.birt.chart.factory
• org.eclipse.birt.chart.render
• org.eclipse.birt.chart.log
• org.eclipse.birt.chart.script
• org.eclipse.birt.chart.model
• org.eclipse.birt.chart.util
The hierarchy diagrams for the org.eclipse.birt.chart.model.*.impl packages are not included because they are simply implementations of the interfaces in the corresponding org.eclipse.birt.chart.model.* packages. The model packages, with two exceptions, contain only interfaces.
The first exception is org.eclipse.birt.chart.model, which has one class, ScriptHandler. The second exception is org.eclipse.birt.chart.model.attribute, which has a set of enumeration classes, one for each attribute. Each of the enumeration classes contains only a list of valid values for its attribute.
chart.aggregate class and interface hierarchy
The chart.aggregate package contains the class and interface that support the aggregate functions that produce the values that a chart shows. Figure 13-10 contains the class and interface hierarchy for org.eclipse.birt.chart.aggregate.
Figure 13-10 Classes and interfaces in org.eclipse.birt.chart.aggregate
chart.datafeed class and interface hierarchy
The chart.datafeed package contains the class and interfaces that support defining a custom data set for a chart. Figure 13-11 contains the class and interface hierarchy for org.eclipse.birt.chart.datafeed.
Figure 13-11 Classes and interfaces in org.eclipse.birt.chart.datafeed
chart.device class and interface hierarchy
The chart.device package contains the classes and interfaces that support rendering a chart to a specific output type. Device adapter classes provide the rendered output. These classes process the events defined in the chart.event package. Display adapter classes provide metrics for the output device. Figure 13-12 contains the class hierarchy for org.eclipse.birt.chart.device.
Figure 13-12 Classes in org.eclipse.birt.chart.device
Figure 13-13 contains the interface hierarchy for org.eclipse.birt.chart.device.
Figure 13-13 Interfaces in org.eclipse.birt.chart.device
chart.event class and interface hierarchy
The chart.event package contains the set of events that a rendering device that extends the chart.device.DeviceAdapter class can support. It also provides structural and caching classes for events. Figure 13-14 contains the interface hierarchy for org.eclipse.birt.chart.event.
Figure 13-14 Interfaces in org.eclipse.birt.chart.event
Figure 13-15 contains the class hierarchy for org.eclipse.birt.chart.event.
Figure 13-15 Classes in org.eclipse.birt.chart.event package
chart.exception class hierarchy
The chart.exception package contains the single exception class the BIRT Chart Engine defines. Figure 13-16 contains the class hierarchy for org.eclipse.birt.chart.exception.
Figure 13-16 Class in org.eclipse.birt.chart.exception
chart.factory class and interface hierarchy
The chart.factory package contains classes and interfaces that build and generate a chart. It also contains a context class that provides information about the environment in which the factory runs, such as the locale and associated localization information. Figure 13-17 contains the class hierarchy for org.eclipse.birt.chart.factory.
Figure 13-17 Classes in org.eclipse.birt.chart.factory
Figure 13-18 contains the interface hierarchy for org.eclipse.birt.chart.factory.
Figure 13-18 Interfaces in org.eclipse.birt.chart.factory
chart.log class and interface hierarchy
The chart.log package contains a single class and an interface to manage logging of the tasks that the BIRT Chart Engine performs. Figure 13-19 contains the class hierarchy for org.eclipse.birt.chart.log.
Figure 13-19 Class and interface in org.eclipse.birt.chart.log
chart.model interface hierarchy
The chart.model package contains the interfaces that describe the available chart types and the factory for generating charts. Figure 13-20 contains the interface hierarchy for org.eclipse.birt.chart.model.
Figure 13-20 Interfaces in org.eclipse.birt.chart.model
chart.model.attribute class and interface hierarchy
The chart.model.attribute package contains classes that define the permitted values for attributes as static fields. Figure 13-21 contains the class hierarchy for org.eclipse.birt.chart.model.attribute.
Figure 13-21 Classes in org.eclipse.birt.chart.model.attribute
The interfaces in the chart. model.attribute provide the getter and setter methods that chart engine objects use to test and set the values of the attributes. Figure 13-22 contains the interface hierarchy for org.eclipse.birt.chart.model.attribute.
Figure 13-22 Interfaces in org.eclipse.birt.chart.model.attribute
chart.model.component interface hierarchy
The chart.model.component package contains the interfaces that define the behavior of all the components that make up a chart. Figure 13-23 contains the interface hierarchy for org.eclipse.birt.chart.model.component.
Figure 13-23 Interfaces in org.eclipse.birt.chart.model.component
chart.model.data interface hierarchy
The chart.model.data package contains interfaces that define a data source, a query structure, and the data components for a chart. These interfaces define getter and setter methods for data set properties and the permitted values for these properties as static fields. Figure 13-24 contains the interface hierarchy for org.eclipse.birt.chart.model.data.
Figure 13-24 Interfaces in org.eclipse.birt.chart.model.data
chart.model.layout interface hierarchy
The chart.model.layout package contains the interfaces that define and arrange the blocks that make up the main components of a chart, such as the plot, title, and legend areas. Figure 13-25 contains the interface hierarchy for org.eclipse.birt.chart.model.layout.
Figure 13-25 Interfaces in org.eclipse.birt.chart.model.layout
chart.model.type interface hierarchy
The chart.model.type package contains the interfaces that define the series for all the available chart types. Figure 13-26 contains the interface hierarchy for org.eclipse.birt.chart.model.type.
Figure 13-26 Interfaces in org.eclipse.birt.chart.model.type
chart.render class and interface hierarchy
The chart.render package contains classes and interfaces that render a chart. Figure 13-27 contains the interface hierarchy for org.eclipse.birt.chart.render.
Figure 13-27 Interfaces in org.eclipse.birt.chart.render
Figure 13-28 contains the class hierarchy for org.eclipse.birt.chart.render.
Figure 13-28 Classes in org.eclipse.birt.chart.render
chart.script class and interface hierarchy
The chart.script package contains the classes and interfaces that support script handling for chart developers to write custom code within the chart class itself. Figure 13-29 contains the class and interface hierarchy for org.eclipse.birt.chart.script.
Figure 13-29 Classes and interfaces in org.eclipse.birt.chart.script package
chart.util class hierarchy
The chart.util package contains classes that support data types and looking up attribute and property values in the literal classes. Figure 13-30 contains the class hierarchy for org.eclipse.birt.chart.util.
Figure 13-30 Classes in org.eclipse.birt.chart.util
