[dojo-contributors] Chart Markup Proposal
eugene at lazutkin.com
Fri Aug 31 02:39:50 EDT 2007
-----BEGIN PGP SIGNED MESSAGE-----
Unfortunately I don't have much time to go over this proposal now, but
I'll do that when I am back (9/10).
Just a small suggestion: check your proposal against the Open Office
Chart specification to see if you missed anything functional-wise. I am
not suggesting to implement everything what's available in OO, but
people spent time thinking about charting, and they (and Microsoft
Office) have a lot of satisfied IT users. It'll make a good source of
reference ("play with your data in OO"), it would be awesome to be able
to export charts from OO. At the very least we have to have a good story
behind "why my favorite feature from the office is not implemented".
You can find the spec here:
- --- look for Chapter 10, which describes all possible parameters, which
can be tweaked for OO charting.
Ben Schell wrote:
> Under Tom Trenka's direction and guidance, I've been doing some
> brainstorming about the markup to be used to create a charting widget.
> These widgets are slated to be developed once the charting engine is
> complete with the intention of making it incredibly easy for a end user
> to create a chart/graph very very simply. As such, there are very few
> required parameters, several optional parameters, and a few 'possible'
> parameters that have been suggested as extra features for these chart
> There are very few parameters needed to create a chart, at the very
> least a data source:
> dojoType="dojox.charting.LineChart" <!-- The chart type. Several
> are planned, see below. -->
> store="someStore" <!-- The dojo.data store to retrieve the data
> from -->
> query="type: Foo" <!-- The query to run on the dojo.data store. -->
> This format requires a few assumptions by the chart widget, most notably
> that the items from the store have the appropriately named attributes to
> be used for the given chart type (in our example, that a given item from
> the data store has a "x" and a "y" attribute). However, this allows an
> end user to very quickly and easily add a chart if they are able to form
> their data store in this format.
> Several optional parameters are then added to allow for a much more
> enhanced chart. The names could depend on the chart type, as a line
> chart has an x- and a y-axis, while a bar chart has an x-axis (which is
> more like an 'index' than an actual x value) and a value-axis (which is
> in fact very similar to a y-axis). Perhaps these might range between x,
> y, value, and size depending on the exact chart type. Here we're using
> a line chart as an example, so the binding and names are all X/Y.
> theme="dojox.charting.GreySkies" <!-- The theme to use for this
> chart. Allows for themes external to the charting tree. -->
> bindings="x:date,y:value" <!-- Allows for data stores that aren't
> in the 'correct' format originally. In this case, the items in the data
> store are expected to have a "data" attribute which would map to the
> x-axis, and a "value" attribute which would map to the y-axis. -->
> rangeX="0 200" <!-- The range to use on the chart's axes.
> This could be (and would be in the simplest case) from the data given. -->
> rangeY="0 20"
> xMajorTick="50" <!-- How often to put major (large) tick marks on
> the given axis.-->
> xMinorTick="10" <!-- How often to put minor (small) tick marks on
> the given axis. -->
> width="600" <!-- The size of the chart. Might it be more
> intuitive to expect these in CSS rather than parameters? -->
> Finally, there are a few ideas that have been brought up as additional
> features to be added to these widgets:
> viewRangeX="50 100"
> viewRangeY="5 15" <!-- Have a 'viewport' on the chart to allow
> the possibility of having a larger chart than is currently in view.
> This would then lead to having controls to pan/zoom around the chart.
> Having the viewable regions smaller than the full chart size is already
> planned for the charting engine, but likely will not be complete
> initially. These parameters will be used to setup the initial chart
> view in the markup.-->
> updateInterval="5" <!-- Re-check the data store this many seconds
> (or maybe milliseconds?) to keep the chart up-to-date with the data
> store. -->
> onUpdate="updateFunction" <!-- Call this function as a callback
> after we've checked the data store and updated the view. Allows the end
> user to do things to the chart (move the view, etc.) when the data is
> updated. -->
> onUpdate="x:20;y:2" <!-- An alternative to the 'functionName'
> idea above, directly tied to whether/when the viewport functionality is
> introduced. The idea here is to move the viewport the given amount on
> each update with each new/changed data point. -->
> As for the chart types that will be supported, it will be very simple to
> abstract much of the 'basic' functionality (which is common to each
> chart type) into some base _Chart widgets that would be built upon by
> the specific chart types. The list of chart types currently planned (or
> considered) are:
> Stacked Area
> Horizontal Bar
> Horizontal Stacked Bar
> Vertical Bar
> Vertical Stacked Bar
> Any comments on any of the above (markup proposal, chart types, etc.)
> are welcome and encouraged.
> Ben Schell
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the dojo-contributors