[Development] URLs in QML/JS

[Hausmann Simon]

Thanks Alan x2 :) Sounds like QUrl bindings are the way to go.

Simon

Alan Ezust <alan.ezust at gmail.com> wrote:



On Mon, Jun 17, 2013 at 2:31 PM, Alan Alpert <416365416c at gmail.com<mailto:416365416c at gmail.com>> wrote:
On Mon, Jun 17, 2013 at 1:32 PM, Hausmann Simon
<Simon.Hausmann at digia.com<mailto:Simon.Hausmann at digia.com>> wrote:
> 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.

I prefer (1), although it should ideally be a 1:1 mapping of
functionality with an API designed for QML. We'll have incompatibility
either way if it's a changing spec. We went with a draft spec for the
QtQuick.LocalStorage API and I don't think that's compatible with how
browsers implement local storage anymore. Better to add the
compatibility in a separate layer/step (which we'll need anyways for
browser objects).

I agree, I'd like to see QUrl (as well as a few other Qt types) in QML with APIs as close to the Qt APIs as possible.
Don't worry about conforming to a standard javascript API until there is one.

Another type I'd like to see in QML is the QTimer type, with notify properties and all.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130619/9de9c1c4/attachment.html>