OK, sounds good. Thanks for your patience. -Darin
On Thu, Oct 22, 2009 at 7:09 AM, Marshall Greenblatt <[email protected] > wrote: > 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 -~----------~----~----~----~------~----~------~--~---
