[Webkit-unassigned] [Bug 116408] [Qt] Support Object construction for window properties added using QtWebKitBridge

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=116408





--- Comment #7 from Arunprasad Rajkumar <arurajku at cisco.com>  2013-05-29 12:48:59 PST ---
(In reply to comment #6)
> We just had a discussion about this.
Thank you :)

> 
> You could support constructor syntax in your application on the JavaScript side if you wrap the factories in JavaScript itself. We assume that this is something you would like to clean up or simplify by moving everything to the C++ side and eliminating any JavaScript side API wrappers.

Yes, exactly :) The current patch allows the new expression on the QtBridge object.

> 
> More generally speaking the question arises: How do you implement complete JavaScript APIs 
(that allow for the use of new expressions, 

The current patch supports the use of new expression,

>function calls where you can access the this object properly,

Sorry, I didn't get you :( Is it similar like bridgeObj.myFunction=function(){ this.x ,... }..?

 modify/setup the prototype chain, etc.) entirely in C++ without JavaScript wrappers?

Are you meaning How to set up prototypical inheritance? bridgeObj.prototype?

> 
> I think the _clean_ solution to that requires a full C/C++ API that is powerful enough to allow for all these things. We could advocate the development of a Qt and C++ based API for that (similar to Qt's QtScript API), but I think a simpler solution that requires less effort and is faster (performance wise) would be to give access to the JavaScriptCore C API.
> 
Looks great, but if JSC C API is directly exposed, the getting/setting properties, method invocation should be handled explicitly. We may loose the power of meta object system in Qt.

> If you have the time and motivation to do the work, I would propose the following approach:

I'm always to ready to take :D

> 
> (1) Add API to QWebFrame that returns a JSContextRef for the frame's window object. (this may require forward-declaring JSContextRef)

> 
> (2) Modify the build system to give access to the JavaScriptCore C API when using QT += webkit-private in .pro files.

I understood your point.

> 
> 
> The former should be a relatively simple patch and the latter (which can be a separate patch for sure) may require a little bit more effort, but would complete the solution.
> 
> What do you think about that?
My worry is user has to take care of implementing JSObjectGetPropertyCallback, JSObjectSetPropertyCallback, JSObjectCallAsFunctionCallback, JSObjectCallAsConstructorCallback,.. But incase of QtBridge, it is taken care by Qt's Object Introspection.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.