[Development] RFC: unified data model API in QtCore => thin wrapper proposal

[Dmitry Volosnykh]

FYI, there's QTBUG-29095 and QTBUG-25723 that feel like somewhat related to
the problem under discussion.

On Mon, Jun 18, 2018 at 2:33 PM Jason H <jhihn at gmx.com> wrote:

> +1 this.
>
> I'd prefer Arne's over the bind below. I do want value updates to be
> emitted so that we only have to change the data to keep dependent
> structures updated. I've suggested having some kind of xpath watcher
> facility...
>
> Having done some web UIs powered by a Ajax, (and qt will undoubtedly power
> some web backends) you need a facility to keep 2 trees in sync - the server
> data and the web UI model.  However it should be the same for QML or widget
> UIs... And in my dream world, a proper QML web UI. But no matter how it
> works, you need to be able to broadcast minimal data changes to the tree to
> listeners (clients).
>
>
>
>
> > Sent: Friday, June 15, 2018 at 3:46 PM
> > From: "Tor Arne Vestbø" <Tor.arne.Vestbo at qt.io>
> > To: "Arnaud Clère" <arnaud.clere at minmaxmedical.com>
> > Cc: "Thiago Macieira" <thiago.macieira at intel.com>, "
> development at qt-project.org" <development at qt-project.org>
> > Subject: Re: [Development] RFC: unified data model API in QtCore => thin
> wrapper proposal
> >
> >
> >
> > > On 15 Jun 2018, at 13:31, Arnaud Clère <arnaud.clere at minmaxmedical.com>
> wrote:
> > >
> > [snip]
> >
> > > Most user-defined bind methods would be very simple and the type
> system would
> > > guarantee that data is well-formed (no sequence or record left
> open...):
> > >
> > >    struct Person {
> > >        QString m_firstName, m_lastName;
> > >        int m_age;
> > >
> > >        template<TResult>
> > >        TResult bind(Val<TResult> value) { return value
> > >            .record()
> > >                .sequence("name")
> > >                    .bind(m_firstName)
> > >                    .bind(m_lastName)
> > >                .out()
> > >                .bind("age" , m_age); // automagically closes opened
> record
> > >        }
> > >    };
> >
> > Not commenting on this API, but I’d like to note that the API I brought
> up as “missing” from my use-case was a more “light weight” in-place edit
> API, where the user does not have to define bindings to data structures
> like above. Similar to e.g. python:
> >
> > >>> data = json.loads('{ "foo": [1, 2, 3] }')
> > >>> data
> > {u'foo': [1, 2, 3]}
> > >>> data["foo"][0] = 42
> > >>> data
> > {u'foo': [42, 2, 3]}
> >
> > With our existing APIs I’d expect:
> >
> > QJsonDocument doc;
> > doc[“foo”][0] = 42;
> >
> > Tor Arne
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20180618/d41d0603/attachment.html>