[dojo-contributors] Chart Markup Proposal
ttrenka at gmail.com
Wed Aug 29 17:26:53 EDT 2007
Let me answer, I'm probably a better resource for that.
> theme="dojox.charting.GreySkies" <!-- The theme to use for
> > this chart. Allows for themes external to the charting tree. -->
> Great. Is this a CSS file? Something more complicated? Is there an
> easy way to customize a standard chart with some additional JS that
maybe gets mixed into it?
It's not a CSS file. There's a Theme constructor sitting in DojoX Charting
right now, which is basically a struct of objects that will be consumed
directly by dojox.gfx. Most of it is stable but I'm still making some
changes to it (in particular, setting it up so that plot area can take
background colors and images as well as the entire chart itself).
There's a number of themes I've already built (theoretically), mostly based
on PlotKit, and they are already in dojox/charting/themes.
There are two issues with trying to use something CSS-like:
1. I'd have to parse that manually and transform it to something gfx can
2. I need the facility to pre-generate a set of colors based on few params,
as well as the ability to iterate on both colors and markers.
In the end, after talking a bit with Eugene, I thought it was best to simply
pre-define things a chart will use, and set up a set of objects I can pass
directly to the various gfx methods (like setStroke and setFill).
> 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"
> Hmm, it seems odd that this one is "rangeX" and the ones below are
> "xMajorTick" -- would it make sense to have the "x" on the same side
> in both? Am I being too pedantic?
No, this is a good idea.
> 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"
> great. Curious as to the defaults of these, and if there is a way to
> turn them off.
Probably this will default to the way the charting engine expects things;
right now, lines and ticks are not drawn by default.
> width="600" <!-- The size of the chart. Might it be more
> > intuitive to expect these in CSS rather than parameters? -->
> > height="400"
> Ideally, setting them in both places is good, as most designers are
> likely to want to do css, and many programmers are likely to want to
> specify in attributes. If I had to pick one, I'd tend toward CSS.
> What's the default behavior if the chart doesn't have an explicit
> width/height specified? Can I make a chart (especially with zooming
> below) that get bigger as the page gets bigger, for example?
That's two questions :P
Again, we're looking at what is fastest for dojox.gfx; in that regard, using
the attributes will be best (need it for dojox.gfx.createSurface). We can
probably parse it out of CSS but I'm not sure I want to open that door ;)
WRT resizing, I think we'll need to wait and see. I don't see any issue
with making chart widgets implement/mixin dijit._Container or
dijit._Contained, but I'd hate to try to do live resizing. Charts *will* be
> > 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.-->
> Sounds like we might also want a "zoom" attribute as well to set
> initial zoom, possibly as an alternative way to do the same thing?
> Is the range in pixels, or units of the chart, or? How will they pan/
> zoom around the chart? One simple method would be just to present
> browser scrollbars, another cooler one would be drag interaction ala
> google maps. Which are you thinking? Is there a way I can specify
> which of those I want to use?
I'm still figuring this out, any suggestions are welcome (that are not
widget-based). My primary inspirations here are audio editors (specifically
Sound Forge), which allow for axis-based zooming as opposed to something
like Google Maps (thinking the zoom and pan controls). However, I would
very much like to try to implement something like the navigator box
available on the bottom right corner of GMaps.
Again, any suggestions are welcome; the idea here is to implement that in
the engine itself, and then make it dead simple for anyone using a charting
widget to use it with default params.
> > updateInterval="5" <!-- Re-check the data store this many
> > seconds (or maybe milliseconds?) to keep the chart up-to-date with
> > the data store. -->
> Seconds sounds good -- anything below that will probably hammer the
> server too often. People can always specify a fraction here if they
> need sub-second.
That interval will be in seconds, not milliseconds--and I'm probably going
to put a hard cap on how quickly it will update, mostly because of the
limitations on browser speed (.5 seconds for a fairly large sized chart is
really pushing the limits of FF/OSX, for instance, and it will peg the crap
out of the CPU).
> 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. -->
> Sounds great. Is this fired before or after the chart is updated?
Probably this function will be what is used to actually update the chart
itself. Still, this is in infancy stages, so any suggestions are definitely
> > 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. -->
> This seems pretty opaque to me, I like the idea, but overloading
> onUpdate with this syntax seems awkward to me. Maybe "updateXDelta"
> and "updateYDelta"? Can I put a negative number in there?
So here's the deal. In general, when people are updating charts in real
time, they are basically changing the range of the x axis while pushing new
data into the system. Since that's the common case, one of the things we'd
like to try to do is set it up so that someone can simply say "on each
update, shift the range of the x-axis by 20 units".
It *is* pretty opaque. And again, we'd love some ideas on how to do that
Tom, the tensioning factor sounds great, and simpler than having a
> whole separate set of chart types for straight|curved. Perhaps
> chartStyle="straight|curved|etc" and/or curviness="3" ?
I'd like to stay away from "curviness" and call it "tension" if we use it;
it may not make immediate sense but as soon as someone plays with it,
they'll see *exactly* what it means.
Again, any and all suggestions please! The focus is "as fricking simple as
possible for someone to make a sweet-ass chart"!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dojo-contributors