[dojo-contributors] Chart Markup Proposal

Eugene Lazutkin eugene at lazutkin.com
Fri Aug 31 02:39:50 EDT 2007

Hash: SHA1

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:
> All,
> 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
> widgets.
> There are very few parameters needed to create a chart, at the very
> least a data source:
> <div
>     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.-->
>     yMajorTick="5"
>     xMinorTick="10"    <!-- How often to put minor (small) tick marks on
> the given axis. -->
>     yMinorTick="1"
>     width="600"    <!-- The size of the chart.  Might it be more
> intuitive to expect these in CSS rather than parameters? -->
>     height="400"
> 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:
> Pie
> Line
> Scatter
> Area
> Stacked Area
> Bubble
> Gantt
> High/Low
> High/Low/Open
> High/Low/Open/Close
> Horizontal Bar
> Horizontal Stacked Bar
> Vertical Bar
> Vertical Stacked Bar
> Pareto
> Any comments on any of the above (markup proposal, chart types, etc.)
> are welcome and encouraged.
> Thanks,
>     Ben Schell
> ------------------------------------------------------------------------
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors

Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the dojo-contributors mailing list