The current state of web applications is a fragmented mess. HTML is still the standard approach, but dynamic data loading with Ajax and application embedding with Flash are both incredibly popular, particularly for data-heavy applications.
HTML is great because it's easy to build and well understood by user agents, but you lack drawing capabilities. SVG addressed parts of that, and if XHTML ever gets adopted in any meaningful way SVG will see a resurgence. The canvas element has stepped in, but it's not universally supported.
Flash is the other end of the spectrum: you have extreme customizability, but developing applications is significantly more work and requires people with a higher skill level than for HTML apps. Flex, OpenLazlo, etc. attempt to ease the developer's pain, but it's still not nearly as easy as HTML. Silverlight (Microsoft's Flash competitor) follows the same vein, though with the addition of binding to Microsoft's technology stack. I'll only be refering to Flash from here out, because as far as I'm concerned here, they're basically equivalent.
Flash also has the significant downside that it's hard to go half way. Applications tend to be either all Flash or all HTML. Static HTML applications can add snippets of Ajax in an incremental fashion where they're best suited without going whole hog. Of course, if you want to go whole hog with HTML, that can be a lot of work too.
But what does this have to do with FlexChart, you ask?
FlexChart provides a way for dynamic HTML applications to leverage the drawing capabilities of Flash in a nearly completely transparent way. If you want to render a chart on a page in a static HTML app, you'll probably employ some server-side technology to build an image and embed that image in the HTML with the IMG tag. But if you want to control the chart's appearance with JavaScript, you're in a bit of a bind, because you have to go server-side to generate a new image and then update the image source with the new URL.
Google Charts provides something of a solution for this problem, because the URL of the image implicitly causes a chart regeneration. So you don't have to manually go server-side, it happens behind the scenes. But as anyone who has worked with the API knows, it can be a bit of a bear to figure out all your data ranges, encode your data, lay out your axes and labels, compute bar widths, etc. Plus, while the number of charts available is pretty good, they're fairly inflexible. For instance, you can't plot a trend line across a column (vertical bar) chart.
FlexChart provides what I feel is a better solution for many applications. It uses a simple XML dialect for specifying both chart structure and the data to display. It leverages the Flex's charting engine to take care of all the chart layout tasks so you don't have to do that. It's designed to be loaded once and draw multiple charts over the SWF's lifetime by passing it new XML descriptors via JavaScript (though it can also be used statically with descriptors from FlashVars). Since it's Flash, it also has the ability to provide interaction with the user. For example, when a user clicks a given data point on your chart, you can detect that with JavaScript and load a new drilled-down chart. The tradeoff is that it's Flash, and while Flash has good penetration, it's significantly behind PNG support (what Google Charts uses), particularly on mobile devices.
As such, FlexChart addresses a narrow slice of the inability/reluctance to build hybrid HTML/Flash applications by providing a JavaScript-centric API for drawing rich charts. Note that this API is not just for drawing static charts, you can register JavaScript functions for handling data tip rendering, click handling, and axis labeling. This allows a very high level of interactivity that I've not seen replicated in any other charting package for HTML/JavaScript applications with similar browser support (or really at all).
Another significant advantage is the technology-neutral XML dialect that FlexChart uses. There is absolutely nothing FlexChart-specific in the structure of the XML, so any charting engine could theoretically read and render the XML. I'm currently in the initial stages of a Google Charts-backed implementation that does exactly that. Yes, that means you can supply FlexChart XML to this new project and get back a Google Charts URL that displays the chart. Obviously it won't be a complete implementation because of limitations in Google Charts (like the mixed line/bar chart issue), but for supported aspects it will be equivalent. This will allow an application to render charts either as Flash (with rich interactivity) or as PNG images (for broad support) without having to change the format used to describe the charts.
Note that the XML descriptor language does NOT provide for the full gamut of capabilities that Flex's charting components have to offer. Nor will it cover all that Google Charts has to offer. The idea is that it provides a simple way to describe most common chart types, and do it in a rendering-neutral way. I've also gone to great lengths to hide much of the complexity that Flex (and soon to be Google Charts) foists on chart developers. For example, Flex forces you to create a huge number of redundant axis references when laying out complicated charts, but with the XML descriptor you can do it once at the top level. In the other direction, Google Charts forces you to explicitly specify all your axis labels and their positions, but the XML descriptor is such that they can be figured out for you by the implementation.
As I alluded to above, if XHTML actually gains adoption and SVG makes a comeback, that's another very likely candidate. I've used an SVG-based charting engine that I wrote five of six years ago on several applications (currently using Batik to conver the SVG to PNGs for display), so that would be another potential implementation. There are several canvas-based charting engines as well, all of which could be potential targets. Finally, there are preexisting XML-configured Flash-based charting packages (FusionCharts is one example). Leveraging one of those packages from the unified XML dialect would come for the cost of some XSL templates. The possibilities are quite promising.
FlexChart itself is only half of the puzzle. Sure, it's greate to have nice charts in a HTML/JavaScript application, but the bigger picture is just as important. Having a single way to describe charts across applications and rendering mechanisms is a huge win. Even more useful is bridging the gap between HTML and Flash with a way to create hybrid applications, instead of people seeing them only as two alternatives. This is a huge win for all web app developers.
Barney,
Does your flexchart allow the line or bars to be a different color. I didn't notice it?
Pat
Patrick,
You bet, both solid colors and gradients. Check out the demo app at http://barneyb.com/flexchart to see some examples of both.
Barney,
Thanks. How does one do a legend below the chart? Also, Can one change the font-size, font-style for the values? How does your code interface with the flex chart components.
Patrick,
legendPlacement="bottom" on the <chart> element. There's no support for font styling at the moment, and I don't have any plans to add it. I develop it in my spare time based on my needs, by and large. The grouped legends stuff was for one of FlexChart's business users, and they paid for my time. Covering development costs is the best way to get on the priority list. ;)
The XML of FlexChart is basically a DSL for chart description (both structure and data), and my code simply interprets that DSL in the context of the Flex's charting components. In a nutshell, my code reads the XML and creates the corresponding charting components based on what the XML says. The grouped legend and the syncing of multiple y-axes are the only custom visualization code that I've written for FlexChart. Reimplementing the DSL in the context of some other charting environment (or even building one from scratch) would be relatively straightforward; that's intentional.
Maybe I'm trying to do this wrong, but if I try to load FlexCharts via a swfloader in Flex 3, how would I load chart data into it? Seems like a great alternative to buying the Pro license.
Currently trying something like:
[Bindable]
public var loadedSM:SystemManager;
private function initBarney():void {
loadedSM = SystemManager(bChart.content);
}
// the loaded application.
private function drawCharts():void {
loadedSM.application["descriptor"] = xmlBarney;
}
private var xmlBarney:XML = <chart type="cartesian" …
Just to follow up, I've switched the code to
private function drawCharts():void {
Object(loadedSM.application).setDescriptor(xmlBarney);
}
In either case, here's the error I'm getting:
Error #2044: Unhandled ioError:. text=Error #2032: Stream Error. URL: file:///C:/Users/Greg%20Ryan/Documents/Flex%20Builder%203/soResume/bin-debug/descriptor.cfm?r=0.32477057399228215
at FlexChart/setDescriptorUrl()
at FlexChart/onInitialize()
That error is quasi-intentional. For backwards compatibility, FlexChart requests descriptor.cfm if it's not provided with a chart descriptor as a flashvar. If you don't have your descriptor when you render the SWF, just supply "
swfobject.embedSWF("FlexChart.swf", "chart", 640, 400, "9.0.28", false, { descriptor: "By supplying the flash var, you'll prevent the automatic request of descriptor.cfm. Once the SWF is loaded, call setDescriptor() on the SWF itself (it's an externalized function) to supply a new one.
As for replacing the FBPro license, it's not really in competition. This widget is a charting widget for JS/HTML applications. FBPro is for building Flex applications, possibly containing internal charts. You'd be hard pressed to cleanly embed FlexChart into a Flex app (though you COULD do it), but you wouldn't get any of the native Flex functionality with it. Two totally separate use cases.
Thanks for the clarification. Ya, I know they're two different use cases and I agree the native functionality may be lost, but I think your charts could stand tall enough as an alternative if you bent it that way. There's plenty of flash charts out there, but I don't know of any other as3 coded charts that can be embedded as another flex app. Anyways, thank you for the quick response, and great job!