Thanks Alan x2 :) Sounds like QUrl bindings are the way to go. Simon
Alan Ezust <[email protected]> wrote: On Mon, Jun 17, 2013 at 2:31 PM, Alan Alpert <[email protected]<mailto:[email protected]>> wrote: On Mon, Jun 17, 2013 at 1:32 PM, Hausmann Simon <[email protected]<mailto:[email protected]>> 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.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
