|
|
   |
Sign In/My Account | View Cart | ||||||||
|
|||||||||
|
|||||||||
|
|
|||||||||
 |
Charts with PHP and Flash, and a port to Perl
Nathan Torkington The Perl port didn't take too long. I spent the most time figuring out what the PHP array-handling code was doing. PHP arrays can be indexed by numeric position (like Perl arrays) or by string keys (like Perl hashes). The PHP code serializes a lot of data structures, and one recurring pattern is code to go through the array by key and value. I saw a lot of code like: $allkeys = array_keys($original_array);
for ($i=0; $i < count($allkeys); $i++) {
print "$allkeys[$i]"."=".$original_array[$allkeys[$i]];
}
Only, of course, they weren't iterating through $original_array, they were iterating through an array buried in a data structure. And it was rare to see just an array being dumped, often it was an array of arrays with concomitant extra levels of obfuscation. The code actually looked like:
$params=$params."rows=".count($chart[ 'chart_data' ])."&";
$params=$params."cols=".count($chart[ 'chart_data' ][0])."&";
for ($r=0;$r<count($chart[ 'chart_data' ]);$r++){
$params=$params."r".$r."=";
for ($c=0;$c<count($chart[ 'chart_data' ][$r]);$c++)
{
$params=$params.$chart[ 'chart_data' ][$r][$c];
if($c==count($chart[ 'chart_data' ][$r])-1){$params=$params."&";}
else{$params=$params.";";}
}
}
(I've fixed their eight-space tabs to spare you the horror of scrolling).It took me a lot of head scratching to verify that my Perl was indeed functionally equivalent to the PHP. Here's what that bit looked like in Perl: $params .= "rows=".@$value."&";
$params .= "cols=".@{$value->[0]}."&";
for (my $r=0; $r < @$value; $r++) {
$params .= "r$r=" . join(";", @{$value->[$r]}) . "&";
}
Anyway, I finally figured it out and generated some pretty graphs. I have to say, it's easy to see why people like it. The Flash output is just beautiful. Unfortunately, in the process of porting the PHP to Perl, I got to find out why I won't be using it.It all comes down to how it works. There are two components to the graphing software: the SWF (Macromedia Flash) file that generates the actual graph, and the HTML that embeds the SWF. The PHP code (and my Perl port of it) simply creates the HTML, which is why it's so short--it doesn't actually do the graphing. The main consequence of this is that when you graph a data set, you have to get that data to the Flash file. You do that by passing the values as URL parameters when you embed it. So the HTML contains something like <EMBED SRC="charts.swf?r0=;2001;2002;2003&r1=Region A;100;20;30">. The first and biggest problem with the Flash charting system is that these data parameters are sent to the web server when the Flash file is requested. So you're now at the mercy of your browser and web server for the maximum amount of data you can graph. No good if you're looking to graph dozens of books over hundreds of weeks, as we are. The second problem is that your data's all hanging in the HTML! Consequently, anyone can grab your data with a minimum of fuss (whereas PNG or GIF charts don't reveal the data set to the same degree). I realize that may seem petty and a form of evil data-hoarding, but some of our data suppliers (e.g., the Bookscan folks who give us Neilsen-like sales figures for technical books) require that we not redistribute their data. The third and final problem is that you have to fetch the flash.swf file for each graph. The browser can't cache it because your parameters to the request are different, so you end up transferring a 189k SWF file for each graph you want to create. That's not to say that the Flash graphing software is bad. It's not, it's beautiful and it fills a certain need very well. It just happens to not fit with my requirements. As a result, I now have my Perl port waiting for someone to adopt it. If you like the Flash charting and want to maintain a Perl port of the PHP wrapper, drop me a line (gnat AT oreilly.com) and I'll gladly turn it over to you. I'm also back on the scrounge. A coworker is playing with SVG::TT::Graph to generate SVG files, but it requires a plugin download and takes a while to render. I'm less than enthusiastic. Another coworker has written an Inline::Java wrapper for jfreechart which I'll be looking at today. I investigated and discarded gdchart and its Perl wrapper as too difficult to build and make work. I had hoped that gnuplot would have been turned into a C library with a thin command-line wrapper, but it is still a monolithic application. The search goes on, and I'll report on it here. --Nat Nathan Torkington is conference planner for the Open Source Convention, OSCON Europe, and other O'Reilly conferences. He was project manager for Perl 6, is on the board of The Perl Foundation, and is a frequent speaker on open source topics. He cowrote the bestselling Perl Cookbook.
Any suggestions of charting software for me?
You must be logged in to the O'Reilly Network to post a comment. 
Showing messages 1 through 18 of 18.
| |||||||||||||||
|
||||||||
| Contact Us | Advertise with Us | Privacy Policy | Press Center | Jobs | Submissions Guidelines Copyright © 2000-2008 O’Reilly Media, Inc. All Rights Reserved. | (707) 827-7000 / (800) 998-9938 |
||||||||
