[dojo-contributors] Chart Markup Proposal

Ben Schell ben.schell at gmail.com
Wed Aug 29 17:27:26 EDT 2007

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20070829/825f1868/attachment.htm 

More information about the dojo-contributors mailing list