Could this also be used as a general pattern to batch DOM updates from multiple Widgets performing updates? e.g. a current approach to avoid the overhead, of say, installing a dozen widgets, is to concatenate all the HTML together, slam it into innerHTML, and then wrap the widgets around the HTML. But this rather breaks the nice OO design people are used to with widgets. Templating is an alternative, but I'm wondering, why can't we make all of the attachment stuff happen via a batch queue. A special optimizer on the queue could even recognize instances of when DOM updates can be coalesced and leverage documentFragment or innerHTML. e.g.
VerticalPanel vp = ... vp.add(new Label()) vp.add(new Label()) The objects are constructed, but the HTML mutations are deferred/queued. When adding a DOM mutation to the queue, you could check if existing queue data isOrHasChild the new DOM mutation element, and if so, just modify the queue element (coalesce) rather than appending another queue item. Then, when processing the queue, you only need to add the roots to the DOM, attaching/modifying enmasse. This would preserve the OO-ness of constructing widget hierarchies without requiring 'foreign' string-based templating. -Ray On Wed, Sep 2, 2009 at 5:13 PM, Bruce Johnson <[email protected]> wrote: > On Wed, Sep 2, 2009 at 6:07 PM, Scott Blum <[email protected]> wrote: > >> I do agree with John that we should really discuss how this can be >> implemented. > > > It's already implemented! > > >> Is there some magic trick to make the browser execute a piece of code at >> the time you want, or do we need to go and modify all our event code (like >> with the global uncaught exception handler)? > > > No trick, it's as bad as you'd hope it wasn't. On the positive side, it's > already been done -- I'm just augmenting the tests for the various > subsystems such as RequestBuilder and event dispatching to make sure we > tighten the correctness noose as much as possible. > > Longer term, Bob and I both would really like to find a general mechanism > for making this pattern easy to do from any path into a GWT module from "the > outside", exactly along the lines of what Matt was talking about. I think > rolling this functionality into gwt-exporter (and then rolling that sort of > functionality directly into GWT proper) will get us pretty far down the > road. > > Code review request forthcoming, possibly tomorrow. > > -- Bruce > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
