Asp chart component

Recently, a client approached me about adding a new requirement to their software--a hybrid content-management application written in ColdFusion, Java, and Flash. The desired new requirement was the ability to create dynamic Gantt charts on various pages in the Web application.

As you may already know, ColdFusion comes out of the box with a very powerful charting and graphing engine, and your first instinct would likely be to use those features (the CFCHART engine). Unfortunately, the complexity of Gantt charts is beyond the scope of what can be achieved easily with the charting engine built into ColdFusion. What's more, the charts had to be dynamic, not dependent on any one OS or browser version, not require having to purchase any additional software, load fast for the clients, and be easy for any designer or developer to drop into the application and have control over every aspect of the look and feel of the charts. To make matters worse, I had three days to create a functional prototype. What would you do?

Before we continue, I'll give you a brief explanation of Gantt charts. In simple terms a Gantt chart is a chart that plots things that are measurable by units of time. Often times, a single "subject" being plotted will have several entries in the timeline. For example, a Gantt chart would be a perfect way to represent time spent out of the office for all of the employees at a company. The chart would span some period of time--let's say an entire year. Measurement labels would go across the top (months, quarters, days, or weeks, for example) and down one side would be a label for each employee. Alongside each employee label, plotted, would be one or more colored shapes representative of vacation time and sick time taken by that employee. The width of the shape shows how long that particular vacation or sick leave lasted, and its start and end positions represent the actual start and end dates. You may have already seen and used Gantt charts without realizing it. Now that we all know what a Gantt chart is, let's get back to the original question--given all of the requirements and restrictions I describe above, what would you do?

Once I had ruled out using the ColdFusion charting engine (yes, that was the first thing I looked into), I immediately looked around on the Web for free third-party tools like applets and ActiveX controls. Unfortunately, nothing I found was as flexible and lightweight as my client required...not for free and/or not that could be implemented in three days and in a way that would be easy for designers and developers to use. Ideally, I'd have enough time to create a generic Gantt Charting Flash movie. A Flash movie could easily be embedded in pages, could be parameterized in order to give developers/designers control over the UI settings, and could use Flash Remoting and/or Web services to talk to the application server and get data and other information required to draw a chart. Unfortunately, creating and testing something as generic and flexible as a Flash movie was not an option given the three-day time limit I faced. I turned to SVG.

SVG stands for scalable vector graphics. It's an official recommendation of the World Wide Web Consortium (W3C) for defining graphics in XML format. SVG is similar to Flash in that it requires the client to have a plug-in (an SVG plug-in in this case) and in that it allows you to create and manipulate images. Because SVG is simply a rendering of what's defined in an XML packet, there's no scripting language built into it per se, but that doesn't mean that you can't make things extremely dynamic and user interactive. SVG exposes itself to the browser as a DOM, and as such it can be manipulated with JavaScript. User interaction, animation, and many other useful bits of functionality are usually relatively easy to achieve. I chose SVG because it's browser independent, free, has very robust graphical capabilities, and because SVG graphics are defined using XML.

ColdFusion has very good support for XML and I have a lot of experience creating APIs using custom tags and CFCs, so I knew it was a good option. I also like the fact that in the future, if time allows for a generic Flash component to be created in order to render charts, that Flash component need only know how to parse SVG XML and render it visually. The API I wrote and all of its accompanying business logic would remain the same--only the component that the XML is handed off to would need to change. All of the ins and outs of SVG are beyond the scope of this article. For more on SVG visit the W3C SVG homepage at www. w3.org/Graphics/SVG/. There's also an excellent tutorial at www. w3schools.com/svg/default.asp, and there's quite a bit of useful information on the Adobe Web site as well. In this article we'll explore how the API prototype works.

To understand how the API works you have to be familiar with ColdFusion custom tags and be vaguely familiar with the basics of XML--you can learn about XML at www.w3schools.com/xml/default.asp.

Custom tags were used to create the API because custom tags are invoked using tag syntax, so they're easy for designers and anyone else who knows HTML or CFML to use. They encapsulate all of the logic required to do what they do and run it in a "protected" environment (variables in the tag don't overwrite variables in the caller page), which allows the API to be safely integrated with any application, and the chart API must write to the screen. I am a firm believer that custom tags, rather than ColdFusion Components, are the ideal place to encapsulate code that is part of the display tier in a CF application. Tags can also be nested within each other with nice clean syntax, which is ideal for an API like this. Creating a chart is easier when you place one <CF_CHART> tag in a file and then nest <CF_CHARTITEM> tags for each of the data sets to plot.

The only thing the tags need to do is output the XML text that represents the data you want to represent. According to the SVG specification, SVG XML consists of tags that define shapes (rectangles, circles, polygons, etc.) all nested inside of a base "SVG" tag. The API itself only needs two tags--one to create the container and one to create a shape within that container. (These shapes represent the data being plotted in the chart and this tag is called repeatedly to represent multiple data items on the chart.)

There are three ways SVG can be used in a browser:

1. A client can browse directly to an SVG .le

2. SVG XML can be embedded inline within an XHTML document

3. An external SVG file can be embedded within a non- XHTML-compliant HTML document

Because the charts need to be embedded in pages containing other content, Option 1 wasn't an option for me. Unfortunately, the application for which I initially created the chart API isn't XHTML compliant, so Option 2 was out also. This left me with Option 3--embedding a separate SVG file. Of course, the chart needs to be dynamic, so rather than linking to an actual SVG (XML) file, pages will link to a CFML file (using the same syntax as if it were SVG text), and that file will dynamically output SVG XML for the plug-in to render.

One hurdle I hit came in the form of blank pages constantly being rendered during testing. As with any good developer, I not only encapsulated business logic but I also used structured exception handling and validate all data. Typically this should be performed in the tag you pass attributes to. If you recall, in order to generate the chart I passed chart information to the "wrapper" tag to create the chart container and to a "chart item" tag in order to render individual entries on the chart. Unfortunately, these tags render XML which is then passed to the SVG plug-in ... and the SVG plug-in won't render anything unless it's valid SVG XML text. So, in order to be able to catch errors thrown from the API, I implemented the "front controller" design pattern and created one tag that sits in front of the API. This tag validates all of the data for the API, calculates new height/width values for the entire chart if it needs to (the outer container must be high and wide enough to hold all of the shapes being plotted, for example), writes all that data to the session scope, and then makes the <embed> call to another CFM file (that calls the SVG XML rendering tags based on what's in the session scope).