[webkit-dev] DeviceOrientation/Motion on Document rather than Page

[Eric Seidel]

My apologies for derailing your earlier discussion.  I just was in
Document.cpp again yesterday and my mind was blown by the madness that
is that god-class.  Then you posted about adding to Document (which
sounds like the right corse of action here!) and I took advantage of
your post for my stop-pooping-on-Document PSA.

I too have 100% confidence in Dean here. :)  As Maciej says, it's just
a controller on Document.

Carry on.

-eric

On Tue, Aug 17, 2010 at 8:50 AM, Dean Jackson <dino at apple.com> wrote:
>
> On 17/08/2010, at 12:22 AM, Maciej Stachowiak wrote:
>
>>
>> On Aug 16, 2010, at 10:52 PM, Eric Seidel wrote:
>>
>>> Where-ever it goes, please don't put it on Document directly. :)
>>> (Feel free to tie it to Document's lifetime, just don't add to
>>> Document's 300+ methods.)
>>>
>>> The madness must stop...  Document is long overdue for some weightloss...
>>
>> I assume Dean is suggesting that Document would gain a new data member (DeviceMotionController?) which strikes me as a reasonable approach.
>
> Right - either one or two (+DeviceOrientationController). I do think the controllers of both events could be a single object - but that is another discussion.
>
> If it wasn't on Document, what do you suggest otherwise? DOMWindow? Putting it on Frame but tying it to Document seems less than perfect.
>
> Dean
>
>>
>>>
>>> -eric
>>>
>>> On Mon, Aug 16, 2010 at 11:43 PM, Dean Jackson <dino at apple.com> wrote:
>>>> Hi,
>>>>
>>>> I've been looking into implementing the clients for DeviceOrientation/Motion Events. Currently, the controllers for these events are members of Page. I think they are better suited on Document.
>>>>
>>>> Here are a few reasons:
>>>>
>>>> - Page isn't tied to any actual web page or document. Would we want to share the same controller and client across multiple web pages? I don't think so.
>>>> - Document is already the place that is listening for these events
>>>> - It's easy to suspend and resume the client from the Document-level when the user navigates to another page, or the document enters the cache, or a platform needs to temporarily suspend events for some reason.
>>>> - When the API is on Page, it is hidden in the WebView, from where it is difficult to access.
>>>> - it would allow the client to live in WebCore. This avoids tweaking the WebView implementations for all platforms to pass messages back and forth
>>>> https://bugs.webkit.org/show_bug.cgi?id=41616
>>>>
>>>> I assume one of the advantages of having them on Page is that it allows a Mock Controller to be easily created for testing from Dump Render Tree. Am I right? Is this that important?
>>>>
>>>> FWIW, Geolocation seems to take both approaches. One implementation is down in Navigator/Document/DOMWindow, but the mock controller is on Page. I've found the low-level approach much easier to implement.
>>>>
>>>> Thoughts?
>>
>> For this sort of thing, it seems reasonable to me that there is a layer of the implementation that is a per-document controller, and then below that a singleton object in case we don't need things to happen multiple times per document. It doesn't seem especially helpful to have something happen at the Page level, in normal operation.
>>
>> The reason it seems a singleton would be useful is that you only want to register with the OS service once, and then multicast the relevant notifications to all clients that are listening.
>>
>> For purposes of substituting a mock controller:
>>
>> (1) If there is a singleton beneath the per-document controllers, perhaps the mock object can insert itself at that level.
>> (2) Even if the mock controller is at the per-document level, it is likely still sufficient for most tests; it might mean a little extra work if we need to specifically test geolocation or device motion/orientation from a subframe.
>>
>> Regards,
>> Maciej
>>
>
>