On Mon, Jun 17, 2013 at 2:31 PM, Alan Alpert <[email protected]> wrote:
> On Mon, Jun 17, 2013 at 1:32 PM, Hausmann Simon > <[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
