[dojo-contributors] Chart Markup Proposal
ttrenka at gmail.com
Wed Aug 29 17:39:34 EDT 2007
One thing Ben didn't mention in his proposal is the binding system. In the
0.4 engine, I provided a way of mapping properties of objects to specific
values needed by the engine; this system is still in place in the new
engine. This way, you could do something like this:
date -> x
value -> y
We're still trying to figure out the best way to handle this with the
widgets, so any suggestions there would be welcome as well. One thought was
something like this:
but we're open.
On 8/29/07, Ben Schell <ben.schell at gmail.com> wrote:
> See inline...
> 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
> dojox.charting.themes currently).
> > 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. -->
> > Great
> > > 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!
> > -Owen
> > _______________________________________________
> > dojo-contributors mailing list
> > dojo-contributors at dojotoolkit.org
> > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dojo-contributors