[dojo-contributors] Chart Markup Proposal

Tom Trenka 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:

bindings="date:x, value:y"

but we're open.

trt

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


More information about the dojo-contributors mailing list