Well, if you'd seen the FusionCharts plugin code, you'd understand why we want to start again. It started life as a quick and dirty way of building strings to hand to the Google chart API, for a few simple chart types. Then one of our users (a big FusionCharts fan) took that, and as as a first attempt at Fabrik plugin, built the first cut of the fusioncharts plugin. Since then, it's been hacked on by a few more people, including myself, usually when we have a specific need to make it "do something else". The code is ... horrible. I've spent hundreds of hours inside it, and I still understand how / why it does a lot of what it does, LOL!
And yes, we probably would allow direct input of native options, with NVD3.
But the problem is really more basic than that, involving the basic method for letting people actually structure their datasets. The UI mechanics of telling us what data you want from which tables, and how your want it "summed" and "grouped", and how that data is represented in the tables.
Take for instance the data in the example you pointed at:
http://bl.ocks.org/mbostock/3887051
If you look at the data, it is neatly presented with separate colums for the age groups. But in Fabrik usage, it is very unlikely you would have data formatted like that. You would be more likely to have ...
state,value,age_group
al,1234,1
tx,2345,2
ca,2354,1
... etc. In other words, a single value field, and an "age_group" field which would probably be a join to an "Age Group" lookup table, or a dropdown element. And it would be very unlikely to be a simple "one row per state", it would most likely be multiple rows per state.
In order to get the neatly "separated by age group, one row per state" data, you would probably have to create a MySQL view of your data table, which does all the summing and splits it out into pre-calculated elements. Which in and of itself might not be trivial, and requires creating your view by hand, no GUI help from us.
You said in a previous message:
I would like to go one step further to suggest that the supplied dataset is plotted as is, and no further summation is done on the datasets. So the user must supply a completed dataset if he wants to plot correctly.
Which is obviously what I'm talking about above. But of course that means the user having enough experience / knowledge to build a neatly summed and rowed view for us to operate on. Which doesn't exactly describe out average user. In the above example, splitting out per-age group sums into different fields would be quite a long and involved query.
What I suggest is that we come up with some example data, in a couple of formats that are the most likely formats Fabrik users would tend to want to graph.
My standard test data is "Pie Sales". I have a list of pie sales, by pie type, looking something like:
id, pie_type_id, quantity, date
... (plus other fieds, for customer, PayPal IPN details, etc), with pie_type being a join to pie_types, which looks like:
id, pie_name, pie_price
In other words, a basic pie sales system. I have a Buy Pie form, with a PayPal plugin, which records into pie_sales. And I've built a variety of graphs, based either on my raw Fabrik tables, or views, which chart that data in a variety of way.
We don't have to use this, but I'd suggest we come up with a couple or three typical scenarios for Fabrik usage which people would want to graph. And that we (whoever is interested in working on the new stuff) all set up those examples, and use those to work out the most common charting requirements, and the UI needed to support them.
-- hugh
