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 <[email protected]> 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 <[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? >> >> 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 [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
