[dojo-contributors] Chart Markup Proposal
owen at smartsoul.com
Wed Aug 29 16:49:21 EDT 2007
Ben, looks really great and super powerful/easy to use. A few of off-
the-top-of-my-head comments/questions about the formats inline. If I
didn't say anything, I think the proposal is great as-is.
On Aug 29, 2007, at 1:04 PM, Ben Schell wrote:
> 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?
> 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?
> 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. -->
great. Curious as to the defaults of these, and if there is a way to
turn them off.
> width="600" <!-- The size of the chart. Might it be more
> intuitive to expect these in CSS rather than parameters? -->
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?
> 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?
> 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
> 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?
> 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?
> 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
Wow, that's hot!
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" ?
Great work, I can't wait to see this!
More information about the dojo-contributors