[Interest] remoteobject returning a list of remoteobjects

[Marc Van Daele]

Thanks for your reply!

Let's see if I understood your correctly (and some additional questions)

   - If I don't need signals and slots on my Person class, I should use a
   POD.  PROP(QList<Person*> persons) will be supported but whenever something
   changes in the list or any property of any item in it, the complete list
   has to be resent (there is only a single personsChanged signal)
   - If I do need signals and slot on my Person class, Person should be a
   rep-class (nested inside Household)
      - I can create a MODEL(persons) [can you give a pointer of this
      syntax? I couldn't find much info on MODEL].
         - This will behave as if the model was local to the client.  Slots
         can be called on the items in the model, signals of the model and the
         individual items in the mode can be received.
         - Is it correct to say that the HouseholdReplica contains a model
         of PersonReplica (pointers) and the HouseholdSource contains
a model of
         PersonSource (pointers) ?
         - Can both the client and the server add rows (new Persons) to the
         model?
      - Can I also create a PROP(QList<Person*> persons)?
         - Is it correct to say that the HouseholdReplica contains a QList
         of PersonReplica pointers?
         - Are the PersonReplica's automatically linked to the
         corresponding PersonSources?  Or should I somehow link them myself to
         ensure that a slot called on the 2nd PersonReplica ends up in
the correct
         PersonSource?
         - Can I add/remove Persons both from client and server side?

Kind Regards,

Marc


On Mon, 22 Apr 2019 at 16:17, Stottlemyer, Brett (B.S.) <bstottle at ford.com>
wrote:

> Hi Marc,
>
> On 4/20/19, 6:46 AM, "Interest on behalf of Marc Van Daele" <
> interest-bounces at qt-project.org on behalf of marc.van.daele90 at gmail.com>
> wrote:
>
>     Hello,
>
>     I'm trying to understand the remoteobjects component.
>     Suppose I have, on my backend, a Household containing a list of
> Persons.
>
> The intent is for Qt Remote Objects to allow what Qt allows, with the only
> constraint being that queued connections be supported.  So you should
> design your interface as you would for standard Qt in-process interaction,
> and not have to modify it for QtRO.  If that doesn’t work (there are a few
> unsupported cases), please file a bug report.
>
>     I guess I'll have a rep file like
>     class Person
>     {
>        //some properties, slots and signals
>     }
>     class Household
>     {
>         PROP(QList<Person> persons)
>     };
>
>     Now I wonder
>     • Is this a valid approach?
>
> No, this isn't valid, as it wouldn't work in a queued connection.  Only
> QObject *pointers* can be used in queued connections, as QObjects are not
> copy-able.
>
>     • will the persons property result in a list of PersonReplica on the
> client side and in a list of PersonSources on the server side?
>
> In this specific case, no, for the above reason.  There are a number of
> alternatives available, depending on the complexity of the types involved.
>
> For simple types, I recommend using a POD in the .rep interface
> definition.  This resolves to a Q_GADGET, basically a struct with a
> metaobject defined.  Signals and slots aren't supported on PODs, though.
> These are only data containers, but a QList of them is supported.  A
> potential downside here is that changing any single value would require the
> entire list to be resent.
>
> QtRO also supports QAbstractItemModel based types, using the MODEL keyword
> in the .rep file.  This has the advantage of allowing individual rows or
> fields to be adjusted, and scales to large numbers of records.
>
> Lastly, you could a nested subclass using the CLASS keyword in the .rep
> file.  This has the advantage of allowing a nested object with its own
> signals and slots.
>
> So there are several options, with the hope that you can design for what
> makes sense from a user/API perspective and QtRO doesn't get in the way.
>
>     • how can I link a specific PersonReplica object to the corresponding
> PersonSource object?
>
> With PODs (or a QList of PODs) as a property, you can replace the objects
> and assign the new value via the setter, which will propagate the new value
> to any Replicas.  With QAIM, you just change the model values on the Source
> and QtRO handles propagating the changes.  Nested CLASS objects work like
> just like other QObjects, and you assign the object itself via the
> generated setter on the Source.
>
>     • where should this linking be done?
>
> Does the above answer this question?  If not, can you rephrase?
>
> Regards,
> Brett
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20190422/85f8f5b2/attachment.html>