[dojo-contributors] Chart Markup Proposal

Brian Douglas Skinner skinner at dojotoolkit.org
Wed Aug 29 19:29:11 EDT 2007

Hopefully Jared can chime in on this too, but here's my thinking...

> One thing we need to keep in mind is that charts (especially 
> large charts) can take a long time to render, particularly if 
> there are a lot of points on it.  

Yup, understood.  Although, in the case of handling a few onNew() 
notifications, the chart might be able to very quickly draw a few new 
data points on the existing plot, rather than needing to re-render the 
entire plot.

> I'm not interested in throttling unnecessarily but at the same 
> time if we're talking about something pushed to the desktops of, 
> say, a Fortune100 company with a lot of Windows 2000 machines all 
> running FF1.5, the perception will end up being "Dojo sucks", and 
> that's not something I want to foster.
> At the same time, we could probably do something where update 
> notifications are caught by the charting engine and rendered 
> periodically.  

That sounds good.  It seems like a useful idea to set things up so that 
update notifications don't automatically trigger a re-rendering.  The 
updates and update notification could still happen frequently, but the 
charting widget could buffer them and then choose to only re-render 
after a given interval.

> The main thing to think of here is to let the charting widget 
> determine when an update is made (as opposed to a Store); from 
> experience I've found that this is (by far) the best method.

I'm not sure I'm parsing that sentence correctly.  If the word "update" 
basically means "re-rendering" (rather than changing the data in the 
datastore cache), then the sentence makes sense to me, and it sounds 
like a good plan.  Am I reading it right?

> Plus we need to consider that the chart widget itself may be 
> the one asking the store for the update...

Right now we don't have any way for a widget to ask the store for an 
update.  That's not a pattern we've designed for.  The closest thing you 
could do is re-issue the original fetch() query again, and then process 
the results a second time, and a third time, and so on -- but if you did 
that, you'd have to either (a) blindly redisplay the entire result set 
even though probably no data has changed, or (b) do a diff to compare 
the old result set to the new result set, and only redisplay if there's 
been a change.  You'd have less screen flicker and/or less code in the 
widget if you watched for onNew/onDelete/onSet notifications and only 
re-render then, after you find out a change has really happened.

:o) Brian

More information about the dojo-contributors mailing list