[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 #7 from anewtobi at gmail.com ---
(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).

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, &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);
}

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!
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.

-- 
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/9c46ae3b/attachment-0001.html>