Chart Package Overview


If you plan to do significant Java code development with KavaChart, you should obtain a copy of the KavaChart User's Guide.  This document has an extensive discussion of KavaChart's architecture, and has many Java code examples to illustrate various coding approaches.

This chapter provides a quick overview of KavaChart's organization and usage.

Overall Organization

KavaChart comprises a set of reusable software components that are combined to form complete charts. These components are stored in individual classes that may be standalone classes or extensions of other classes. Significantly, the classes can be recombined in new ways to form new chart types, or they can be extended to leverage pre-existing functionality.

Visual Engineering provides a set of pre-constructed complete charts that combine these components in a uniform way. These chart classes are uniformly named [chart-type]Chart.class; e.g. BarChart.class AreaChart.class, LineChart.class and so on. They also all extend the Chart abstract superclass, which provides functionality common to all charts, such as adding datasets, installing a background, and so on.

Generally, one of the preconstructed Charts will meet your needs. We have provided source code for each of these specific Chart subclasses so you can see how to create your own combinations.

Every chart includes one or more Dataset classes, a Background and a Plotarea class, and a few other necessary utility classes. Each chart also contains one or more graphical components, such as a Line class (responsible for rendering an array of Dataset classes in a line chart form) or a Pie class (responsible for rendering a Dataset class in pie chart form).

Many component classes are dependent on other components. For example, an Axis class requires an array of Dataset classes and a Plotarea class so that it may scale properly and draw itself in the correct location. The Chart abstract class and the specific chart type classes combine these components in a coherent fashion.

Subclassing is used extensively to share common functionality in KavaChart. For example, Axis is a superclass to LabelAxis, DateAxis, and SpeedoAxis. All these subclasses re-use significant portions of Axis's functionality, and inherit most of their properties from the Axis superclass.

KavaChart also uses Java interfaces in a few strategic places to enhance the package's flexibility and to facilitate KavaChart use within an application's GUI. KavaChart includes interfaces for Axis, Legend, and Chart classes. Should you choose to extend KavaChart classes for your own use, we recommend implementing these interfaces for continuing compatibility.


Properties

Internally, KavaChart classes each rely on a set of properties to define the look or behavior of a particular class. A programmer can gain access to these properties in a variety of ways.

Generally, programmers will use the access methods available for each class to manipulate a class' properties. These access methods are uniform throughout KavaChart, using signatures recognized by Java's  introspection facility. A sample access method pair from our Axis class is as follows:

To change the label angle for a particular chart's Y axis to 90 degrees, then, you'd use something like this: The properties of a particular class also include that class' companion classes, e.g. an Axis' Dataset classes. You can manipulate these properties in the same fashion you would manipulate simple class properties. For example, you might use something like this to cause KavaChart to scale a Y axis for theoretical data instead of actual data: Properties are initialized to reasonable default values, so that a simple chart probably doesn't need to change too many properties. However, an extensive set of properties lets you easily create a signature look for your application's charts.

The KavaChart applet collection uses HTML parameters to set most chart properties.  The server objects use the same property/value pairs for constructing chart images. If you're building applets or server objects, such as servlets, you can re-use KavaChart's property handlers to automate property handling.  See the KavaChart User Guide for more information on how to do this.

Many of the properties you'll be most interested setting come from KavaChart's Gc class. This is a utility class that stores values for graphical attributes like colors and images. Almost every KavaChart class has at least one Gc associated with it. You will quickly come to appeciate this uniformity in you own code, as you can develop uniform ways to deal with all sorts of graphical attributes. Here are a couple of examples of using the Gc class:

Note that  you can also group property setting functions together:

A Few Interfaces and One Abstract Class

KavaChart uses a variety of Interfaces to assist you in dealing with classes in a uniform way. For example, you don't need to know if a particular axis is a linear-scaled Axis, a log-scaled axis, a FinanceAxis, a LabelAxis, a SpeedoAxis or a DateAxis. Certain functionality is guaranteed to exist because these axes implement AxisInterface. You can also install a variety of axis styles on a single chart, as long as the Axis conforms to AxisInterface.

In KavaChart, interfaces are available for Chart,Legend, and Axis. These exist primarily to provide design guidance to individuals who wish to add new classes to KavaChart while re-using existing classes. For example, if an individual wanted to build an axis system with labelling based on Fibonacci sequences, she could still use Line, Bar, or any of the other pre-existing KavaChart classes.

Similarly, all sorts of Legends can be implemented without subclassing KavaChart's Legend class. The only requirement, if those legends are going to be used within pre-existing KavaChart classes, is that the new Legend conform to our LegendInterface class.

Chart is a special case. Visual Engineering provides a set of preconstructed complete Chart classes that all extend the Chart abstract class. Chart is implemented as an abstract class to provide common functionality shared by various chart types. It's a sort of safety net to ensure that obscure classes are all initialized, and to simplify specific Chart classes. You can see by the brevity of source code in BarChart.java that this is an effective approach.

ChartInterface provides a uniform way to deal with complete charts.


KavaChart Class Hierarchies

While the chart package doesn't use extensive subclassing internally, it does provide some very useful base classes, and provides insight into how one might extend the base package classes.

Ubiquitous Classes

KavaChart uses a few internal classes everywhere.

Gc is a class for storing graphical properties, such as lineColor and fillColor, as well as methods for drawing. Although Gc doesn't extend the Java Graphics class, you can think of it as KavaChart's conduit to Java Graphics.

DisplayList is KavaChart's internal mechanism for collecting chart geometries and associating these with specific objects. DisplayList's contains() method lets you obtain a list of KavaChart objects at a particular location. Because every chart object that draws something is a candidate for entry into the DisplayList, this class is used almost everywhere.

RotateString is KavaChart's internal utility for rotating labels and other character strings. Since Java doesn't provide any string rotation, the chart package uses raster operations to rotate Java's fonts.

RotateString and DisplayList need to be available to many classes, but creating separate instances of these classes for each chart class would be inefficient and architecturally awkward. To avoid this, we created a special Globals class that stores one instance of these classes and a few properties used by every chart. One instance of a Globals class is available to almost every class in a specific Chart. You probably won't access the members of this class very often, however, because the abstract Chart class provides specific access methods for Globals properties that need to be exposed.


Event Management

KavaChart's chart package is concerned with managing and rendering data using conventional graphical representations. It provides functions for drawing charts, and for identifying chart objects based on locations, but it does not attempt to create entire bound applications. KavaChart's applets provide some of this functionality in the form of robust applets.  In general, we believe event management is better reserved for external layers, rather than being embedded within the core chart package.

By sending a pixel location to any chart's DisplayList class, you can receive a list of chart objects at that location. You can also customize the contents of that list by setting the useDisplayList property for any drawing chart class. By using this functionality, you can acquire property information, data values, or any other information stored within KavaChart's classes.

Since KavaChart doesn't concern itself with managing the flow of events, you're free to implement your own event handlers. Check the KavaChart User Guide for more information on event handling, and for some useful utilities for doing things like zooming and scrolling chart data.