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. > > -eric > > On Mon, Aug 16, 2010 at 11:43 PM, Dean Jackson <d...@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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
