ContentsChartingCoding a new ValueSet type

Previous: Common ValueSet types | Next: Pie charts

At some point, you may need to represent data differently than with the ValueSets that are provided. It's easy to subclass ValueSet for values which are regular. If you need to represent irregular values (such as scatter plots), you should write a class that implements the Renderable interface.

Suppose we need a variant of the BarValueSet which represents it's values as a column of glyphs, where the top glyph may be partial. Not very precise, but easy to interpret.

First off, ValueSet implements the Renderable interface and provides a data array - which is what we need, so we'll subclass ValueSet. Actually, our new class is quite a bit like the BarValueSet; but it doesn't need the ability to stack or offset. On the other hand, it needs to be able to draw glyphs; so we can borrow ideas from both of those classes. The source is provided with the Servlet Utilities and is released as a contribution to the Open Source community. Since it combines some of the capabilities of these two classes, we'll call our new class "GlyphBarValueSet" (but, of course, you could call yours "Ray" :-)

Here's what we get when we create a simplified version of our earlier servlet class and a local lobotomized BarValueSet that we've renamed. code / output

This is what we've done:

• Removed everything but the essentials - personally, I find that it's easier to isolate the problem, get something working, build it up, and then integrate it back into the main development effort (it saves time during each iteration and assures that I understand everything that's going on).
• For now, the source for the new ValueSet subclass will reside in the same source file with it's test harness - the chart5 servlet. We can take it out of "dry dock" when it reaches a level of maturity that warrants being a public class.
• Started with the source of the BarValueSet and removed all extraneous functionality (stackability and offsets). It's important to remove the comments at this point, because there is nothing more misleading than vestigial comments.

What we have now is a rather simple bar chart, but we can see the essential behavior at work. We know that our constructor is wrong, however, because it doesn't allow us to specify the glyph geometry or the pitch (i.e. the repeat distance) of the glyph pattern. Consequently, we also know that our new class also doesn't have a place to store this information. When we make the changes to accommodate these characteristics, here's what we get. code / output

No visual difference, right? That's because we haven't fixed our render method to draw the glyphs. Instead of drawing a bar, we want to set the clip rectangle and repeatedly draw the glyph until we are sure that the top-most glyph has been drawn. code / output

ContentsChartingCoding a new ValueSet type

Previous: Common ValueSet types | Next: Pie charts