It occurs to me that as part of this markup proposal, probably an explanation of what the engine itself will support would be a good idea. &nbsp;So in that spirit, here&#39;s what I&#39;m looking at:<div><br class="webkit-block-placeholder">
</div><div>Held over from 0.4:</div><div>&gt; Property mapping (i.e. myProp-&gt;x);</div><div>&gt; Pluggable plotting (see below on this one); i.e. if you have a specific type of plotter you need that the engine doesn&#39;t have, you can write your own and use it without any kind of registry;
</div><div>&gt; Plot overlaying: the idea that you can put any number of Plots on a single chart, each with either distinct or shared axes (it makes any kind of combination charts *very* easy to do).</div><div>&gt; Updating: the new engine will retain the ability for you to add new data and re-render both data lines and axes based on passed info.
</div><div><br class="webkit-block-placeholder"></div><div>New for 0.9+:</div><div>&gt; Theming</div><div>This is one of the biggest changes (outside of infrastructure). &nbsp;Basically, you can define a theme (it&#39;s an object but essentially a JSON-based structure) and that&#39;s what a chart will use to render itself. &nbsp;In addition, you will be able to switch themes on the fly. &nbsp;Everything a chart needs for visual rendering is available in a Theme, and you can define piecemeal (the system will mix your theme in with the default one, so that if you&#39;re only looking for, say, a background image under the plotarea, you can do that).
</div><div><br class="webkit-block-placeholder"></div><div>Anything that dojox.gfx supports with most shapes can be used as part of a theme def, with two exceptions: both the entire chart and the plotarea can also take a background image reference, and the engine will generate the necessary code for rendering. &nbsp;Also, based on browser support, you can turn anti-aliasing off or on--though admittedly this may be spotty (mostly due to the way various browsers implement things).
</div><div><br class="webkit-block-placeholder"></div><div>(Note that background image rendering is *vector-based* and not what you&#39;d expect with CSS; if you think you&#39;ll be able to do background-repeat with this, it will depend entirely on dojox gfx and the pattern fills, support for which is still spotty (thanks, IE)).
</div><div><br class="webkit-block-placeholder"></div><div>&gt; Custom markers</div><div>Instead of simply defaulting to circles to show points on a plotter such as a line, you have the ability to specify a marker to show exactly where a point is. &nbsp;There are a number of pre-defined markers, and you have the ability to create custom markers of your own, based on SVG paths...basically, you define a path based on the starting point (starting point is the actual coordinate of the data representation, and the system will prepend that value to your path as an absolute value), and the engine will simply use your definition in conjunction with the theme to put markers on a chart.
</div><div><br class="webkit-block-placeholder"></div><div>&gt; Targeted rendering</div><div>The new engine includes a way of telling a chart to re-render only the parts of a chart that need it; you can do this by passing an array of values to the chart&#39;s 
<i>invalidate</i> method (or none at all, which tells the engine to redraw everything). &nbsp;This will cause the chart to either redraw immediately (if the chart is static), or it will keep the changes queued (in the case of a timed update).
</div><div><br class="webkit-block-placeholder"></div><div>&gt; Event stubs</div><div>A chart object has a number of event stubs for you to connect to, so that you can create things like custom tooltips. &nbsp;Only certain things on a chart will fire some of the interactive events (
i.e. only clicking on a marker will fire onClick)...right now these names are standard event names but if anyone has suggestions, I can add them now.</div><div><br class="webkit-block-placeholder"></div><div>&gt; DojoX GFX
</div><div>The entire engine is being rewritten to use DojoX GFX.</div><div><br class="webkit-block-placeholder"></div><div>&gt; &nbsp;Simplification of the API</div><div>The 0.4 PlotArea, Axis and Series objects have been eliminated; PlotArea has been consolidated into Chart, and Axis and Series have been incorporated into Plot. &nbsp;The basics of creating a chart programmatically look a little like this (actual args are still in flux):
</div><div><br class="webkit-block-placeholder"></div><div>var chart=new dojox.charting.Chart(args);</div><div>var plot=new dojox.charting.Plot(args);</div><div>plot.setAxis(&quot;x&quot;, { props });</div><div>plot.setAxis
(&quot;y&quot;, { props });</div><div>plot.add([]);</div><div>plot.add({ obj });</div><div>chart.invalidate();</div><div><br class="webkit-block-placeholder"></div><div>The native data format is an array of JS objects; dojo.data
 will *not* be supported directly by the engine (support for dojo.data will be through Dijit wrappers, which should allow you to consume dojo.data.Stores both via markup and programmatically).</div><div><br class="webkit-block-placeholder">
</div><div>When I have something working and checked in, I will provide much better examples of doing a chart than with my original test_engine (which was my selfish test bed as opposed to examples).</div><div><br class="webkit-block-placeholder">
</div><div>&gt; Chaining</div><div>Whereever possible, I&#39;m setting up the engine to be chainable (like gfx is), so you could do something like:</div><div><br class="webkit-block-placeholder"></div><div>plot.add(data0)
</div><div>&nbsp;&nbsp; .add(data1)</div><div>&nbsp;&nbsp; .add(data2);</div><div><br class="webkit-block-placeholder"></div><div>&gt; New plotters</div><div>Will be adding 0D axis charts (pie), new 1D (stacked bars), and a couple of other plotters. &nbsp;Again, suggestions here would be welcome.
</div><div><br class="webkit-block-placeholder"></div><div>Plotters have also been split out into separate resources, so that you can require only the ones you need (as opposed to getting all of them, like the 0.4 engine does). &nbsp;The Line plotter is the default.
</div><div><br class="webkit-block-placeholder"></div><div>&gt; Legend generation</div><div>Legends can be generated; they will not be attached to the &quot;domNode&quot; of a chart, instead you&#39;ll get a dojox gfx surface wrapped in a block node, and you can append that where you need it in your page. &nbsp;Legends will include the color, marker and title of all data series (if provided).
</div><div><br class="webkit-block-placeholder"></div><div>---</div><div>Future directions</div><div>Once the engine is checked in and working relatively bug free, I&#39;m planning on the following enhancements:</div><div>
<br class="webkit-block-placeholder"></div><div>1. Zoom and Pan, with navigator</div><div>Individual axes will be zoomable, with a drag/pan type system in place. &nbsp;Still trying to figure out the best way to do this UI wise, but right now my inspiration is being drawn from audio editors (specifically, Sony Creative&#39;s Sound Forge). &nbsp;Suggestions welcome.
<br><br>&nbsp;</div><div>2. Sparklines</div><div>I will be creating a constructor (at the same level as Chart) for inline sparklines, optimized for small rendering. &nbsp;In theory, creating a sparkline would look like this:</div><div>
<br class="webkit-block-placeholder"></div><div>var sl=new dojox.charting.Sparkline(node, w, h);</div><div>sl.plotter=dojox.charting.plotters.Bar; &nbsp; // Line will be the default, using for illustration purposes.</div><div>
sl.add(data)</div><div>&nbsp;&nbsp; &nbsp;.invalidate();</div><div><br class="webkit-block-placeholder"></div><div>// alternately</div><div>var sl=new dojox.charting.Sparkline(node, w, h, theme)</div><div>&nbsp;&nbsp; &nbsp;.add(data)</div><div>&nbsp;&nbsp; &nbsp;.invalidate();
</div><div><br class="webkit-block-placeholder"></div><div>I figure only a few plotters will be allowed to be used with sparklines: pie, line, bar, area, maybe bubble. &nbsp;Thoughts on this are more than welcome.</div><div><br class="webkit-block-placeholder">
</div><div>...</div><div>You know, there was a couple of other enhancements I was looking at but right now I&#39;m not remembering them. &nbsp;Oh well--if there&#39;s something I missed, ask and I&#39;ll answer.</div><div><br class="webkit-block-placeholder">
</div><div>trt</div><div><br><div><span class="gmail_quote">On 8/29/07, <b class="gmail_sendername">Tom Trenka</b> &lt;<a href="mailto:ttrenka@gmail.com">ttrenka@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
Inline.<br><br><div><span class="q"><span class="gmail_quote">On 8/29/07, <b class="gmail_sendername">Brian Douglas Skinner</b> &lt;<a href="mailto:skinner@dojotoolkit.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
skinner@dojotoolkit.org</a>&gt; wrote:</span></span><span class="q"><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
Hopefully Jared can chime in on this too, but here&#39;s my thinking...<br><br>&gt; One thing we need to keep in mind is that charts (especially<br>&gt; large charts) can take a long time to render, particularly if<br>&gt; there are a lot of points on it.
<br><br>Yup, understood.&nbsp;&nbsp;Although, in the case of handling a few onNew()<br>notifications, the chart might be able to very quickly draw a few new<br>data points on the existing plot, rather than needing to re-render the
<br>
entire plot.</blockquote><div><br>&nbsp;</div></span><div>It doesn&#39;t really work that way. &nbsp;Most of the charts in question will be based on paths, which expect a full path definition as opposed to being able to just append a few points to the end of it; it kind of sucks but that&#39;s the way it works :(&nbsp;
</div><span class="q"><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; I&#39;m not interested in throttling unnecessarily but at the same<br>&gt; time if we&#39;re talking about something pushed to the desktops of,
<br>&gt; say, a Fortune100 company with a lot of Windows 2000 machines all<br>&gt; running FF1.5, the perception will end up being &quot;Dojo sucks&quot;, and<br>&gt; that&#39;s not something I want to foster.<br>&gt;<br>

&gt; At the same time, we could probably do something where update<br>&gt; notifications are caught by the charting engine and rendered<br>&gt; periodically.<br><br>That sounds good.&nbsp;&nbsp;It seems like a useful idea to set things up so that
<br>update notifications don&#39;t automatically trigger a re-rendering.&nbsp;&nbsp;The<br>updates and update notification could still happen frequently, but the<br>charting widget could buffer them and then choose to only re-render
<br>after a given interval.</blockquote><div><br>&nbsp;</div></span><div>Right, exactly what I was thinking.&nbsp;</div><span class="q"><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">

&gt; The main thing to think of here is to let the charting widget<br>&gt; determine when an update is made (as opposed to a Store); from<br>&gt; experience I&#39;ve found that this is (by far) the best method.<br><br>I&#39;m not sure I&#39;m parsing that sentence correctly.&nbsp;&nbsp;If the word &quot;update&quot;
<br>basically means &quot;re-rendering&quot; (rather than changing the data in the<br>datastore cache), then the sentence makes sense to me, and it sounds<br>like a good plan.&nbsp;&nbsp;Am I reading it right?</blockquote><div><br>

</div></span><div>You are, in fact :)&nbsp;</div><span class="q"><br><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; Plus we need to consider that the chart widget itself may be
<br>
&gt; the one asking the store for the update...<br><br>Right now we don&#39;t have any way for a widget to ask the store for an<br>update.&nbsp;&nbsp;That&#39;s not a pattern we&#39;ve designed for.&nbsp;&nbsp;The closest thing you<br>could do is re-issue the original fetch() query again, and then process
<br>the results a second time, and a third time, and so on -- but if you did<br>that, you&#39;d have to either (a) blindly redisplay the entire result set<br>even though probably no data has changed, or (b) do a diff to compare
<br>the old result set to the new result set, and only redisplay if there&#39;s<br>been a change.&nbsp;&nbsp;You&#39;d have less screen flicker and/or less code in the<br>widget if you watched for onNew/onDelete/onSet notifications and only
<br>re-render then, after you find out a change has really happened.<br></blockquote></span></div><br><div>That&#39;s true, and that&#39;s what I was thinking about (the former). &nbsp;There&#39;s an unfortunate disconnect when it comes to timed things and non-timed things, and (like I said, from experience) I kind of need to support both :(
</div><div><br>&nbsp;</div><div>Fortunately the charting engine was designed so that you can take the &quot;main&quot; axis (usually x), set the range on it, and then filter out values that don&#39;t fall within it, but that may incur some additional overhead as well (think BETWEEN in SQL).
</div><div><br>&nbsp;</div><div>trt</div>
</blockquote></div><br>&nbsp;</div>