At the end of the second article we were left with a spring graph
that looked like this:

Figure 1. Initial graph

This allows us to see direct relationships between keywords, and
also see their relative popularity. It does leave a few things to be
desired though. To start with, we’ve no way of seeing the actual
occurrence counts of each keyword, and since we’re scaling the font size
in fixed increments, there can be a considerable difference in counts
between keywords that display at the same size.

Adding more text to the graph will probably make it a little messy,
and the exact occurrence count is more of a secondary piece of data that
people will drill down to if they’re interested in gleaning more
information. With this in mind, a good way to proceed is to add a
tooltip—this way the user can mouse over any keyword they’re interested in
and see the info they want, without it clogging up the graph
unnecessarily.

The easy way to do this is to add the count to the toolTip attribute on our item renderer. Let’s
try doing this now:

<sg:SpringGraph
  id="mySpringGraph"
  backgroundColor="#FFFFFF"
  lineColor="#6666ff"
  repulsionFactor="5"
  right="10" left="10" bottom="10" top="10">
  <sg:itemRenderer>
    <mx:Component>
      <mx:VBox
        cornerRadius="5"
        backgroundColor="0x444444"
        paddingBottom="5"
        paddingLeft="5"
        paddingRight="5"
        paddingTop="5"
        toolTip="{data.data}">
        <mx:Label
          text="{data.id}"
          fontSize="10"
          color="0xFFFFFF"
          textAlign="center" />
      </mx:VBox>
    </mx:Component>
  </sg:itemRenderer>
</sg:SpringGraph>

If you look at the toolTip
attribute that we added to the VBox in
our inline item renderer component, we’re passing it the
data key in our object. This might appear confusing:
just remember that what’s being passed to the item renderer is always
given the reference data in Flex, and it just so
happens that our Item class has a property called
data, which we’re using to store the keyword
occurrence count. If our property in the Item class
was called occurrence_count, the code would look like
this:

toolTip="{data.occurrence_count}"

Save the above code—and when you mouse over a keyword in the
resulting spring graph, you should see a tooltip like this:

Figure 2. Simple tooltips

This works, and proves that we can push our information through to
the tooltip, but is neither attractive nor particularly helpful. Ideally
we want prettier interface, and one big enough to contain some extra text
like “Mentioned in 12345 Threads.”

Before we begin though, a note on best practice. In part
II, we simply created our item renderer inline—it was easier and
allowed us to explore the concept without a lot of code architecture
getting in the way. However, in the real world, it’s much better to create
an independent class for the item renderer. Doing so provides us with
encapsulation and allows us to reuse the same tooltip in multiple places,
should we wish to. In the context of this spring graph application, it may
make little sense to you to separate these elements, especially if you
lack experience working with larger projects. In the long run, however, I
guarantee you’ll find life much easier if you follow these principles.
Remember, when it’s a tiny demo application it seems like a lot of work,
but once your codebase reaches several hundred thousand lines of code, it
will be much simpler to debug, refactor, or modify any part of your
application if you’ve followed this sort of best practice.

The whys and wherefores of architectural best practice are beyond
the scope of this article, so for now I’ll just lay out a simple way to
structure the code. If you’re new to this, I highly recommend you do some
reading on Flex architecture and design patterns, and perhaps look into
some of the frameworks like Mate and Swiz.

In order to separate out our item renderer, we need to create a new
class. In your src directory you should have a
subdirectory named com. Inside
com, create a directory named
sitepoint, then inside that create another directory
named itemrenderers. This method of laying out
folders is sometimes called reverse domain
notation, and is just a handy way of separating code from
different projects. As long as the paths are correct, Flex is unconcerned
with where our code lives—we’re creating subdirectories purely to make it
easier to manage as the codebase grows or as you combine code from
different projects into one. In our case, you can see we already have a
directory—adobe—inside our com
directory; this is where the Adobe JSON serialization classes live.
Already you can see how sticking to this domain notation automatically
protects us from any naming clashes and keeps it all nice and
clean.

Now inside the Flex Navigator pane, right-click the
itemrenderers folder and choose
New, then MXML
Component. Call it KeywordRenderer.mxml
and base it off VBox. You should end up with a new file whose contents
look like this:

<?xml version="1.0" encoding="utf-8"?>
<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" width="400" height="300">
</mx:VBox>

The code we need to complete the renderer is similar to the inline
version we built in the last tutorial—the complete file should look like
this:

<?xml version="1.0" encoding="utf-8"?>
<mx:VBox
  xmlns:mx="http://www.adobe.com/2006/mxml"
  cornerRadius="5"
  borderThickness="1"
  borderStyle="solid"
  backgroundColor="0x444444"
  paddingBottom="5"
  paddingLeft="5"
  paddingRight="5"
  paddingTop="5">
  <mx:Label
    text="{data.id}"
    fontSize="{parentDocument.getFontSize(data.data)}"
    color="0xFFFFFF"
    textAlign="center" />
</mx:VBox>

Now that this is complete, we go back to our main
.mxml file and make a couple of changes. Remove the
inline component—everything inside and including the <sg:itemRenderer> tags. It should end up looking
like this:

<sg:SpringGraph
  id="mySpringGraph"
  backgroundColor="#FFFFFF"
  lineColor="#6666ff"
  repulsionFactor="5"
  right="10" left="10" bottom="10" top="10" />

Note that I’ve removed the end tag and added a trailing slash to the
start tag, because we no longer need to nest anything inside it. We’ll
also need to move the font stepping code (which we wrote in Part II) of
the series to inside the item renderer class. This will prevent us from
having to use the parentDocument call to the font
function. It’s always a good idea to keep your components from being
dependent on the rest of your code, so they can be reused without
modification.

As our font method relies on data calculated in the main
application, we’ll need to pass it in as a series of parameters. We can
just copy and paste the getFontSize method into
our new item renderer, and then add declarations for the public variables
like so:

public var dataMin:Number;
public var dataMax:Number;
public var fontMin:Number;
public var fontMax:Number;
public var fontLift:Number;

To allow us to set these parameters, we’ll need to assign the
itemRenderer in our main application file. Let’s add
that to the setup method, just before the line
where we assign the dataProvider-:

var factory:ClassFactory = new ClassFactory(KeywordRenderer)
factory.properties = {fontMin:fontMin, fontMax:fontMax, fontLift:fontLift, dataMin:dataMin, dataMax:dataMax};
mySpringGraph.itemRenderer = factory;
mySpringGraph.dataProvider = myGraph;

Here we’re creating a ClassFactory and
setting the parameters we need in an array
(factory.properties), then assigning the factory as the
item renderer for our spring graph. We need to do this in our script,
since we’re unable to set parameters if we simply assign it as an
attribute in our MXML tag.

Your final KeywordRenderer.mxml should look
like this:

<?xml version="1.0" encoding="utf-8"?>
<mx:VBox
  xmlns:mx="http://www.adobe.com/2006/mxml"
  cornerRadius="5"
  borderThickness="1"
  borderStyle="solid"
  backgroundColor="0x444444"
  paddingBottom="5"
  paddingLeft="5"
  paddingRight="5"
  paddingTop="5"
  buttonMode="true"
  mouseChildren="false"
  useHandCursor="true"
  click="this.searchForums()"
  toolTip=" "
  toolTipCreate="createCustomToolTip('Mentioned in '+formatter.format(data.data)+' threads', event)">
  <mx:Script>
    <![CDATA[
      import mx.events.ToolTipEvent;
      import com.sitepoint.tooltips.KeywordToolTip;
      private var sitePointSearchURL:String = "http://www.sitepoint.com/forums/search.php?q=";
      public var dataMin:Number;
      public var dataMax:Number;
      public var fontMin:Number;
      public var fontMax:Number;
      public var fontLift:Number;
      private function createCustomToolTip(title:String, event:ToolTipEvent) : void {
        var ktt:KeywordToolTip = new KeywordToolTip();
        ktt.message = title;
        event.toolTip = ktt;
      }
      private function getFontSize(data:Number) : Number {
        var fontSize:Number = (data - dataMin) / fontLift;
        if (fontSize < fontMin) {
          return fontMin;
        } else if (fontSize > fontMax) {
          return fontMax;
        } else {
          return fontSize;
        }
      }
      private function searchForums() : void {
        navigateToURL(new URLRequest(sitePointSearchURL+data.id), "_self");
      }
    ]]>
  </mx:Script>
  <mx:NumberFormatter id="formatter" />
  <mx:Label
    text="{data.id}"
    fontSize="{getFontSize(data.data)}"
    color="0xFFFFFF"
    textAlign="center" />
</mx:VBox>

If you compile and reload your application, nothing will have
changed … perfect! That’s exactly what you want! When refactoring, the
goal is to keep the behavior of the application the same, while providing
the warm fuzzy feeling of knowing you’ve architected your code properly
for the future.