[Development] URLs in QML/JS

Hausmann Simon Simon.Hausmann at digia.com
Mon Jun 17 22:32:22 CEST 2013


Here's one bit in QML that's been bothering me a bit, and I'd like to do
something about it. But since it involves new API it requires a discussion and

The problem: URLs in QML are inconsistent and hard to use. When reading a URL
property (for example a C++ QObject with a property of type QURL), it is
somethings wrapped as a string (when it happens so that the binding goes
through the v4 interpreter), or it is wrapped as a completely opaque variant.
It is hard to use, because the common things you may want to do with a url -
such as inspecting the parsed portions or building a new URL - are impossible
due to the lack of API. It appears that the most reliable way of for example
verifying if a URL is of a certain scheme is to call toString on it and then
apply a regular expression.

I'd like to make URLs a better supported citizen in the world of QML's
JavaScript, and it appears that a few options present themselves:

(1) We could just create more or less a 1:1 API mapping of QUrl. A url object
in JavaScript would continue to have a toString method, for convenient
processing with functions that expect strings. But otherwise it would have
properties such as scheme, authority, path. Unfortunately the formatting options of
QUrl's C++ API don't seem to map very well to a JS property based API, so we'd
have to stick with the defaults (PrettyDecoded?)

(2) There appears to be development towards creating a specified URL JavaScript
API in the world wide web. The most recent spec appears to be from the whatwg:
http://url.spec.whatwg.org/ and it seems quite reasonable, as well as
https://dvcs.w3.org/hg/url/raw-file/tip/Overview.html. However those are drafts
and therefore likely subject to change, I think.

Can anyone see a clear preference of (1) over the (2)? (1) is non-standard and
likely to cause incompatibility issues in the future when integrating with
third-party JS libraries. OTOH (2) may take who-knows-how-long until it finalizes.

Also, would an "API addition" in that sense require a QtQml version bump (with
regard to imports)?


More information about the Development mailing list