[Webkit-unassigned] [Bug 136989] WebKit2 Gtk+ JavaScriptCore bindings doesn't work properly

[bugzilla-daemon at webkit.org]

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

--- Comment #8 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #7)
> (In reply to comment #6)
> > Thanks for the patch. I think the long term solution would be to have
> > GObject bindings for JSC API, but for now I guess we need something current
> > WebKit bindings could use. However, I'm not sure adding _as_string is the
> > best approach.  Why as_string and not also as_number, as_bool, etc.? I
> > prefer if we add something like as_gvalue() for example, that would work for
> > bindings, but would also be more convenient to use for C API users and would
> > cover all possible values of the result that can be represented as a GValue.
> 
> I agree with the long term solution.
> 
> Why as_string and not as_number and as_bool?
> 
> Because numbers and bools can (and do) automatically get "stringified" (I
> don't mean from the JS-code side, I mean by JSValueToStringCopy), so numbers
> and booleans are also "covered" with this solution with little extra "costs"
> and nothing extra to maintain. Furthermore the assumption can be made that
> people will send complex data as JSON strings with JSON.stringify and than
> decode the JSON with something like JSON.loads (in python).

In that case maybe it would be better to use to_string() since we are converting the value to a string in some cases.

> The as_gvariant / as_gvalue idea, also occured to me, but seeing that
> strings can be very easily converted to ints/floats/booleans in python and
> also seeing that JSON.stringify (js) and JSON.loads (python) work flawlessly
> through postMessage()/as_string, I saw little need for as_number, as_bool or
> as_gvariant as it would complicate the code a little bit (I mean in the
> webkitjavascriptresult implementation, but also when you're using the API in
> python). I'm not against as_gvalue, but I'd like to have as_string, as it
> makes the python code really simple.
> 
> Also consider this example in the documenation from:
> https://lazka.github.io/pgi-docs/index.html#WebKit2-4.0/classes/WebView.
> html#WebKit2.WebView.run_javascript_finish
> 
> static void
> web_view_javascript_finished (GObject      *object,
>                               GAsyncResult *result,
>                               gpointer      user_data)
> {
>     WebKitJavascriptResult *js_result;
>     JSValueRef              value;
>     JSGlobalContextRef      context;
>     GError                 *error = NULL;
> 
>     js_result = webkit_web_view_run_javascript_finish (WEBKIT_WEB_VIEW
> (object), result, &amp;error);
>     if (!js_result) {
>         g_warning ("Error running javascript: %s", error->message);
>         g_error_free (error);
>         return;
>     }
> 
>     context = webkit_javascript_result_get_global_context (js_result);
>     value = webkit_javascript_result_get_value (js_result);
>     if (JSValueIsString (context, value)) {
>         JSStringRef js_str_value;
>         gchar      *str_value;
>         gsize       str_length;
> 
>         js_str_value = JSValueToStringCopy (context, value, NULL);
>         str_length = JSStringGetMaximumUTF8CStringSize (js_str_value);
>         str_value = (gchar *)g_malloc (str_length);
>         JSStringGetUTF8CString (js_str_value, str_value, str_length);
>         JSStringRelease (js_str_value);
>         g_print ("Script result: %s\n", str_value);
>         g_free (str_value);
>     } else {
>         g_warning ("Error running javascript: unexpected return value");
>     }
>     webkit_javascript_result_unref (js_result);
> }

Note that this example only uses JSValueToStringCopy if JSValueIsString() return true, to make it clear that we are expecting a string and getting a string.

> That's a lot of boilerplate code simply to get a string. I imagine that
> getting a string is a common end result you want from javascript_finish and
> from messageHandlers. In C you can at least do it, but look at how much code
> that is!

I agree, and that's why I said it would work for bindings but also would make the API more convenient.

> Now you can you use as_string in this C example and be done. So, this is an
> additional reason for having as_string beyond just enabling python scripts
> to use the API at all.

I agree, yes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150914/ea1add38/attachment.html>