[dojo-contributors] Chart Markup Proposal

Tom Trenka ttrenka at gmail.com
Fri Aug 31 10:33:18 EDT 2007


>
> Unfortunately I don't have much time to go over this proposal now, but
> I'll do that when I am back (9/10).


Thanks, I'd appreciate it.

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".


>From a quick scan, it doesn't seem like I'm missing all that much; basically
a surface plotter (which is something I'd like to do anyways) and a few
minor variations on the way things are defined (plus the 3D defs such as
Wall and Floor, but I'm not going to concern myself with this yet--not until
we've incorporated gfx3d and Neil's code).  A quick reading suggests that
the engine is actually a superset of what they provide (i.e. we do more than
they specify), and that many of the definitions they have can almost be
mapped directly.

Any examples of the XML for some charts would be good; the spec uses XSI but
I do much better with actual examples...and I can definitely write something
that will serialize dojo.charting.Charts to OOXML without too much trouble I
think.  Parsing the other way shouldn't be a problem either (though it will
take a little more work), so this is definitely something we can look at
post-1.0.

trt

You can find the spec here:
> http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1-html
> /OpenDocument-v1.1.html
> - --- look for Chapter 10, which describes all possible parameters, which
> can be tweaked for OO charting.
>
> Thanks,
>
> Eugene
>
> 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.
> -->
> >></div>
> >
> > 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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFG17bPY214tZwSfCsRAk1gAKCZcXnp1vnBhtU05RQRmk5Uy9d+4gCeNPV4
> DrQcKJ86FVNt9G6Kkc2zLjU=
> =/ibI
> -----END PGP SIGNATURE-----
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20070831/e847145e/attachment.htm 


More information about the dojo-contributors mailing list