I had struggled with how to extend the Chart and/or GD::Graph
modules to better "mate" with the DBI apps I'm targeting.
It needed to be able to handle output directly from DBI
bound parameters (ala bind_col()), needed a comprehensible
specification language (ala SQL) instead of a mishmash of hashes,
and I wanted to try to leverage an existing, documented, widely
disseminated interface specification, rather than throw yet
another interface spec on the already teetering pile. Being
a DBMSgeek, DBI seemed the obvious solution.
I suppose some could argue DBD::Chart just tosses another
SQL dialect on that already teetering pile. However, at least for
my apps, being able to use DBI as a common base class
with minimal differences (mostly SQL) between various
implementation instances allows the application
code to treat everything like a DBI-thingy (files, dbms's, charts,
maybe others ?), which greatly simplifies things. Maybe I'm
overloading DBI, treating it like Java beans or OLE components, but
it works for me...
Anyway, I'm proceeding in this direction for now, if it turns into
a fiasco, I'll backtrack and see what can be done with Chart or GD.
After all, until the DBI maillists become charitable organizations,
I'm just using my time...8^}