Hi Darin, On Thu, Oct 22, 2009 at 2:50 AM, Darin Fisher <[email protected]> wrote:
> Marshall, > For now, can you just use NPObject to access the DOM? See WebBindings for > implementation of NPRuntime methods. > > Long term, I am interested in reflecting the full DOM via the WebKit API, > but I don't want to rush the design. At present, we are pretty busy just > trying to complete the core WebKit API. I want to stay focused on that. > I completely understand your priorities and support the desire not to rush the design of new features for inclusion in WebKit. CEF uses reference-counted C++ classes so I think directly accessing WebKit or WebCore objects will simplify the implementation as compared to using NPObjects. For now I'll proceed with my own WebCore DOM wrapper implementation as part of CEF. I should have lots of good suggestions when the time comes to discuss the wrapper implementation for WebKit :-). > > -Darin > > > On Tue, Oct 20, 2009 at 5:28 PM, Jeremy Orlow <[email protected]> wrote: > >> Darin knows for sure, but I'm not aware of any intentions on Google's part >> to engineer such an elaborate API. As long as it didn't add a >> major maintenance burden (i.e. exposed things similar to one of the other >> WebKit APIs) I'd imagine patches would be welcome though. >> I believe only Darin can speak to this authoritatively, though. >> >> J >> >> >> On Tue, Oct 20, 2009 at 4:00 PM, Marshall Greenblatt < >> [email protected]> wrote: >> >>> On Tue, Oct 20, 2009 at 5:33 PM, Adam Barth <[email protected]> wrote: >>> >>>> It seems like we need to draw the line somewhere. Otherwise, we'll >>>> end up exposing the whole DOM via the WebKit API. Where do you think >>>> the optimum cut-off is? >>>> >>> >>> I think treating the DOM as an XML-ish object tree would be the most >>> reasonable approach. This means: >>> >>> 1. The ability to walk the DOM hierarchy by following parent/child >>> relationships. >>> 2. The ability to get/set DOM attributes. >>> 3. The ability to create/delete DOM objects at any level in the >>> hierarchy. >>> 4. The ability to set event listeners on DOM objects (perhaps using a >>> v8::Function as the listener). >>> >>> Inputs would need to be sanity-checked by the API based on the underlying >>> object context, but I don't think we need to provide separate API >>> classes/methods for each possibility. >>> >>> >>>> Adam >>>> >>>> >>>> On Tue, Oct 20, 2009 at 1:55 PM, Marshall Greenblatt >>>> <[email protected]> wrote: >>>> > Hi All, >>>> > >>>> > The Chromium WebKit API does not currently provide a wrapper for the >>>> > WebCore::Document object associated with a WebCore::Frame. CEF >>>> > (http://code.google.com/p/chromiumembedded), which also uses the >>>> WebKit API, >>>> > would like access to this object at the C++ level. Is there interest >>>> in the >>>> > broader Chromium community for having a Document wrapper as part of >>>> the >>>> > WebKit API? >>>> > >>>> > Thanks, >>>> > Marshall >>>> > >>>> > > >>>> > >>>> >>> >>> >>> >>> >>> >> > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
