++Ray.
On Thu, Sep 3, 2009 at 4:38 PM, Ray Ryan <[email protected]> wrote:
> 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 <[email protected]>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 <[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
-~----------~----~----~----~------~----~------~--~---
