[dojo-contributors] Chart Markup Proposal
ben.schell at gmail.com
Wed Aug 29 17:27:26 EDT 2007
On 8/29/07, Owen Williams <owen at smartsoul.com> wrote:
> 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?
I'm not sure about the full format of themes, but they are in JS. Tom can
probably give more details about this (and there are a few themes in
> 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?
You're right, it'd be a lot wiser to put these in the same format. Perhaps
consider these hereafter as 'xRange="0 200"' and 'yRange="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"
> great. Curious as to the defaults of these, and if there is a way to
> turn them off.
I'm not quite sure what Tom is considering the defaults here, so maybe he
can help out here as well.
> 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?
I'd agree that it'd be nicer to put these in CSS, but I think it'd be
'easier' (for me :) ) if they're attributes, but I'm open to suggestions.
> 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
> need sub-second.
> > 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?
I think the useful thing would be afterwards, when the update of the chart
is fully complete. However, maybe we could make "onUpdateStart" (before the
chart updates) and "onUpdateEnd" ?
> 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?
Sure, negative numbers should be fine.
> 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
> 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!
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dojo-contributors