[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
> 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
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.
More information about the dojo-contributors