I like it a lot Ray. (To be completely honest, I knew you were going to say
all that, so I decided to sandbag and let you do the typing :-)
I question if it's really appropriate to explicitly say "PreEventLoop" and
"PostEventLoop" considering that...sometimes...the event loop can actually
run re-entrantly. Those names sound like a very strong guarantee that I
don't think we can reliably guarantee. It's more like
"PreCurrentJavaScriptStackFullyUnwinding" and "PostEventLoop".
Actually, to take a step back (which is my very favorite thing to do), there
are several kinds of things that could be consolidated:
1) Single-shot timers
2) Recurring timers
3) Incremental commands that run as soon as possible after the event loop
(faster than setTimeout(0))
4) Incremental commands that run after the event loop via setTimeout(0)
5) Deferred commands that run as soon as possible after the event loop
(faster than setTimeout(0))
6) Deferred commands that run after the event loop via setTimeout(0)
7) Execute-this-before-you-unwind-the-JS-stack-in-which-it-was-enqueued (aka
BatchedCommand)
8) Arguably, runAsync (although it's purpose is so functionally different it
would probalby be a mistake to munge it in)
#3 and #5 might look funny, but it is generally possible to run code *after*
the event loop but *much* sooner than setTimeout(0), which is usually
clamped to some pretty long duration such as 10ms. The reason you wouldn't
want to do #3 and #5 as the default for deferred commands is that it would
keep the CPU overly busy if you did it a bunch in a row. It would very
likely drain mobile batteries quickly, even.
@Ray (or anyone): Can you think of an awesome way to reconcile those behind
a consistent API?
On Thu, Sep 3, 2009 at 4:52 PM, Joel Webber <j...@google.com> wrote:
> ++(++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
-~----------~----~----~----~------~----~------~--~---
