The mechanism is just brilliant. I have reservations about the api.
<bikeshed>
"it seemed kinda nice to have one less type"
Except that we have one more type, BatchedCommand, which looks exactly like
Command, except with a different name, and you have to subclass it rather
than implement it...
A simple thing we could do is:
- create com.google.gwt.core.client,
- change com.google.gwt.user.client.Command to extend the new one
- deprecate com.google.gwt.user.client.Command
- And have BatchedCommand accept com.google.gwt.core.client
And the two names, "DeferredComand" and "BatchedCommand", don't give much
clue as to which does what. And of course BatchedCommand doesn't actually
provide any batching service.
If we were doing all this from scratch, I suspect we would wind up with
something like this in core (presuming we're happy with IncrementalCommand
and addPause):
package com.google.gwt.core.dispatch
public interface Command {
void execute();
}
public interface IncrementalCommand {
boolean execute();
}
public class PreEventLoopDispatcher {
public static PreEventLoopDispatcher get(); { ... }
public void addCommand(Command c);
}
public class PostEventLoopDispatcher {
public static PostEventLoopDispatcher get(); { ... }
public void addCommand(Command c);
public void addCommand(IncrementalCommand c);
public void addPause();
}
Note the avoidance of statics to make commands more testable, a recurring
subject.
Seems like we could do this, deprecate the existing classes, and make them
wrappers around the new.
</bikeshed>
On Wed, Sep 2, 2009 at 11:36 PM, Ray Cromwell <cromwell...@gmail.com> wrote:
>
> 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 <br...@google.com> wrote:
>
>> On Wed, Sep 2, 2009 at 6:07 PM, Scott Blum <sco...@google.com> 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
-~----------~----~----~----~------~----~------~--~---
