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