[Development] On QML and keeping data alive.

[Charley Bay]

Rene wrote:

> Hi Qt developers
>
> A little over a year ago I raised a question on this list about
> QSharedPointers and QML, and got a lot of debate started, which turned out
> to be very illuminating. (
> http://lists.qt-project.org/pipermail/development/2012-May/004049.html)
>


> <snip, now clarifying deeper problems, how QML fits in MVC>
>


> <snip>, Clearly I am talking about the difficulties of a database
> application.<snip>,
>
The key is that SHARED OWNERSHIP must take effect during the use of the
> objects in question.
>
> <snip>,
> Now the punch line...
>
> THE CONTROLLER
> ===========================
>
> While I see is as the job of the model to query the database and serialize
> the SQL response into Q_PROPERTIES, I am quite reluctant to wish that
> objects in the model domain should store QSharedPointers and hence be
> responsible for resources being locked in memory as long as their (shared)
> parent keeps them stored.
> Instead I see it as the job of the View/Controller to lay claim to
> resources while they are in use. Why? Because the controller ultimately is
> responsible for actually using the database resource for as long as the
> view exists.
>
> So far I have surprised very few programmers. The MODEL queries and
> serializes data and the CONTROLLER does the resource management deciding
> when it is time to let go of database resources again.
>

Agreed.  IMHO, this is the only significant "design issue" we've run into
with using the QAIM (and there have been discussions on this list in the
past, I can look them up if anyone cares).

A change-to-the-design with this consideration (where the "view" secures
transient resources from the "model") could be done in a number of ways, I
think.  But, I think it's important.


> <snip>,
> SUMMING UP
> ===========================
> By now I think you get the problem (and sorry for being overly verbose).
> QtQuick items makes good views but bad controllers. QWidget based forms are
> fairly good for both. <snip>,
>

Mostly agree, although I also have issues with QWidget-QAIM, in that I want
the "QModelIndex" to have "type-information" OR wholly-contain state, such
as a QSharedPointer<>.

<snip, ASCII art, lifetime of database resources and objects>
>


> But that still leaves out difficult decisions. Continuing on our example,
> let's see how a simple CompanyView.qml could work out, using typical QML
> idioms:
>
> COMPANYVIEW.QML:
> Item {
>     property Company company
>     Column {
>         Text { text: company.name; .... }
>         ListView {
>             model: company.employees <<<<<<<<< PROBLEM: What does this
> mean?
>             ....
>         }
>     }
> }
>
> PERSONVIEW.QML:
> Text {
>     property Person person
>     text: person.name
> }
>
> Look at the place where the ListView is bound to the companys employee
> list. What exactly is being asked of the model here? The semantics are
> unclear. Is QML asking the C++ model to load the employees and then forget
> about the references? I.e. can the C++ model trust the controller to keep
> and store references itself? Clearly the view is accessing the model
> directly, and that leaves out the controller, which should have helped
> store the reference in a guaranteed way.
>
> In all fairness, the problem would also exist in a QWidget scenario. But
> QML is extra difficult, because MVC usage patterns in my opinion aren't
> really clear yet. My current instinct commands that me to make the most
> beautiful interface, i.e. one using QQuickListProperty, which is not very
> intuitive when it comes to custom types, and doesn't give a lot of room for
> dealing with the resource management situation.
>
> Just like last year, I wish for an enriching debate, hoping I have
> demonstrated the need to think usage patterns into the API design.
>
> Best regards,
> Rene Jensen
>
> P.S.: You can always design your way out of most problems, and in this
> case I will probably end up doing just that. But I still wish to hear your
> take on the problem, because I imagine that these issues have been solved
> before.
>

IMHO, this is a tricky problem, that is not just QAIM/MVC.  Specifically, I
think we're talking about "value-semantics" and "reference-semantics" for
instances that bridge across the QML/C++ boundary.  Of course, as Rene
points out, this is a "screamingly-loud-issue" when it comes to database
resources, which is the thrust of his post.

In this case, "value-semantics" in the view ensure the database
resources/objects can be released (and still be represented in the "view"),
while "reference-semantics" in the view ensure the database
resources/objects must persist (in-memory).

I don't have specific suggestions (yet) on what to do.  However, we have
similar issues related to our "data-models" that bridge QML/C++, and even
for other "many-to-many" instances that bridge the QML/C++ boundary (which
comes up a lot in our designs when interfacing directly with
hardware/instrumentation).

My "wimpy" suggestion that I made in the past:  I want "QModelIndex" to
have additional "type-information" that identifies my application-specific
types, OR the ability to wholly contain a QSharedPointer-type thing.

--charley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130815/bb22a659/attachment.html>