See inline...<br><br><div><span class="gmail_quote">On 8/29/07, <b class="gmail_sendername">Owen Williams</b> <<a href="mailto:owen@smartsoul.com">owen@smartsoul.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ben, looks really great and super powerful/easy to use. A few of off-<br>the-top-of-my-head comments/questions about the formats inline. If I<br>didn't say anything, I think the proposal is great as-is.<br><br><br>On Aug 29, 2007, at 1:04 PM, Ben Schell wrote:
<br><br>> theme="dojox.charting.GreySkies" <!-- The theme to use for<br>> this chart. Allows for themes external to the charting tree. --><br><br>Great. Is this a CSS file? Something more complicated? Is there an
<br>easy way to customize a standard chart with some additional JS that<br>maybe gets mixed into it?</blockquote><div><br>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).<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> bindings="x:date,y:value" <!-- Allows for data stores that
<br>> aren't in the 'correct' format originally. In this case, the items<br>> in the data store are expected to have a "data" attribute which<br>> would map to the x-axis, and a "value" attribute which would map to
<br>> the y-axis. --><br><br>Great<br><br>> rangeX="0 200" <!-- The range to use on the chart's<br>> axes. This could be (and would be in the simplest case) from the<br>> data given. -->
<br>> rangeY="0 20"<br><br>Hmm, it seems odd that this one is "rangeX" and the ones below are<br>"xMajorTick" -- would it make sense to have the "x" on the same side<br>in both? Am I being too pedantic?
</blockquote><div><br>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"'.<br></div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> xMajorTick="50" <!-- How often to put major (large) tick<br>> marks on the given axis.-->
<br>> yMajorTick="5"<br>> xMinorTick="10" <!-- How often to put minor (small) tick<br>> marks on the given axis. --><br>> yMinorTick="1"<br><br>great. Curious as to the defaults of these, and if there is a way to
<br>turn them off.</blockquote><div><br>I'm not quite sure what Tom is considering the defaults here, so maybe he can help out here as well. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> width="600" <!-- The size of the chart. Might it be more<br>> intuitive to expect these in CSS rather than parameters? --><br>> height="400"<br><br>Ideally, setting them in both places is good, as most designers are
<br>likely to want to do css, and many programmers are likely to want to<br>specify in attributes. If I had to pick one, I'd tend toward CSS.<br>What's the default behavior if the chart doesn't have an explicit
<br>width/height specified? Can I make a chart (especially with zooming<br>below) that get bigger as the page gets bigger, for example?</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Finally, there are a few ideas that have been brought up as<br>> additional features to be added to these widgets:
<br>><br>> viewRangeX="50 100"<br>> viewRangeY="5 15" <!-- Have a 'viewport' on the chart to<br>> allow the possibility of having a larger chart than is currently in<br>
> view. This would then lead to having controls to pan/zoom around<br>> the chart. Having the viewable regions smaller than the full chart<br>> size is already planned for the charting engine, but likely will<br>
> not be complete initially. These parameters will be used to setup<br>> the initial chart view in the markup.--><br><br>Sounds like we might also want a "zoom" attribute as well to set<br>initial zoom, possibly as an alternative way to do the same thing?
<br>Is the range in pixels, or units of the chart, or? How will they pan/<br>zoom around the chart? One simple method would be just to present<br>browser scrollbars, another cooler one would be drag interaction ala<br>google maps. Which are you thinking? Is there a way I can specify
<br>which of those I want to use?<br><br>><br>> updateInterval="5" <!-- Re-check the data store this many<br>> seconds (or maybe milliseconds?) to keep the chart up-to-date with<br>> the data store. -->
<br><br>Seconds sounds good -- anything below that will probably hammer the<br>server too often. People can always specify a fraction here if they<br>need sub-second.<br><br>> onUpdate="updateFunction" <!-- Call this function as a
<br>> callback after we've checked the data store and updated the view.<br>> Allows the end user to do things to the chart (move the view, etc.)<br>> when the data is updated. --><br><br>Sounds great. Is this fired before or after the chart is updated?
</blockquote><div><br>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" ?
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> onUpdate="x:20;y:2" <!-- An alternative to the<br>> 'functionName' idea above, directly tied to whether/when the
<br>> viewport functionality is introduced. The idea here is to move the<br>> viewport the given amount on each update with each new/changed data<br>> point. --><br><br>This seems pretty opaque to me, I like the idea, but overloading
<br>onUpdate with this syntax seems awkward to me. Maybe "updateXDelta"<br>and "updateYDelta"? Can I put a negative number in there?</blockquote><div><br>Sure, negative numbers should be fine.<br></div>
<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> As for the chart types that will be supported, it will be very<br>> simple to abstract much of the 'basic' functionality (which is
<br>> common to each chart type) into some base _Chart widgets that would<br>> be built upon by the specific chart types. The list of chart types<br>> currently planned (or considered) are:<br>><br>> Pie<br>
> Line<br>> Scatter<br>> Area<br>> Stacked Area<br>> Bubble<br>> Gantt<br>> High/Low<br>> High/Low/Open<br>> High/Low/Open/Close<br>> Horizontal Bar<br>> Horizontal Stacked Bar<br>> Vertical Bar
<br>> Vertical Stacked Bar<br>> Pareto<br><br>Wow, that's hot!<br><br>Tom, the tensioning factor sounds great, and simpler than having a<br>whole separate set of chart types for straight|curved. Perhaps<br>chartStyle="straight|curved|etc" and/or curviness="3" ?
<br><br>Great work, I can't wait to see this!<br><br>-Owen<br><br>_______________________________________________<br>dojo-contributors mailing list<br><a href="mailto:dojo-contributors@dojotoolkit.org">dojo-contributors@dojotoolkit.org
</a><br><a href="http://dojotoolkit.org/mailman/listinfo/dojo-contributors">http://dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br></blockquote></div><br>