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 <dino@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?
Dean
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev