++(++Ray)
Anything we can do to sensibly get this crap out of .user and into .core (or
some other common location) would be very, very good.
If, as a side-effect, we could get DeferredCommand to *not* use
IncrementalCommand (the latter brings in fairly significant dependencies
that are enough to matter for small apps), that would be even better.
On Thu, Sep 3, 2009 at 4:46 PM, Scott Blum <sco...@google.com> wrote:
> ++Ray.
>
>
> On Thu, Sep 3, 2009 at 4:38 PM, Ray Ryan <rj...@google.com> 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 <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
-~----------~----~----~----~------~----~------~--~---
