[Index] [Introduction] [Installation] [Cookbook] [Component] [Chart] [Axis] [Utility] [Applet] [Servlet] [Appndx A] [Appndx B] [API]

FRAMES  NO FRAMES   NO FRAMES INDEX


Chart Package Overview

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 1.1'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. This is a simple way to initialize a wide range of chart properties if your application or applet can use KavaChart's preconstructed applet classes. Since we also provide the applet source code, you can also transfer portions of the applet source code into your own applets to set these properties.

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 because of the way Java passes values by reference, 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 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. Its implementation is certainly not mandatory for dealing with internal KavaChart classes because it's not used internally. Rather, ChartInterface provides a uniform way for you to collaborate with other KavaChart users who may have constructed custom charts. You can see an example of how this is used in our own KavaChart applets.


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

The transition from Java 1.0.2 to Java 1.1 created problems as well as opportunities for Java developers. Java 1.1 and Java Beans provides a healthy event-driven communication mechanism for inter-application communications. However, it also means that most applications written for Java 1.0.2 must be rewritten to take advantage of Java 1.1 facilities.

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 or applets. KavaChart's applets provide some of this functionality in the form of robust applets, and we are working on a set of Java Beans that encapsulates key charting functions into Beans.

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 either 1.0.2 or 1.1 style event management. To make sure you stay up to date on evolving Java  technologies in KavaChart, check our additional resources in Appendix B.


[Index] [Introduction] [Installation] [Cookbook] [Component] [Chart] [Axis] [Utility] [Applet] [Servlet] [Appndx A] [Appndx B] [API]