[chromium-dev] Re: WebKit API wrapper for Document
Hi Darin, On Thu, Oct 22, 2009 at 2:50 AM, Darin Fisher da...@chromium.org 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 jor...@chromium.org 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 magreenbl...@gmail.com wrote: On Tue, Oct 20, 2009 at 5:33 PM, Adam Barth aba...@chromium.org 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 magreenbl...@gmail.com 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API wrapper for Document
OK, sounds good. Thanks for your patience. -Darin On Thu, Oct 22, 2009 at 7:09 AM, Marshall Greenblatt magreenbl...@gmail.com wrote: Hi Darin, On Thu, Oct 22, 2009 at 2:50 AM, Darin Fisher da...@chromium.org 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 jor...@chromium.orgwrote: 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 magreenbl...@gmail.com wrote: On Tue, Oct 20, 2009 at 5:33 PM, Adam Barth aba...@chromium.orgwrote: 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 magreenbl...@gmail.com 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API wrapper for Document
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? Adam On Tue, Oct 20, 2009 at 1:55 PM, Marshall Greenblatt magreenbl...@gmail.com 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API wrapper for Document
On Tue, Oct 20, 2009 at 5:33 PM, Adam Barth aba...@chromium.org 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 magreenbl...@gmail.com 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: WebKit API wrapper for Document
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 magreenbl...@gmail.com wrote: On Tue, Oct 20, 2009 at 5:33 PM, Adam Barth aba...@chromium.org 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 magreenbl...@gmail.com 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: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
