[Development] QtQml value types

[charleyb123 .]

>
> <snip, use QVariant Maps to transfer property data between C++ and QML>
>


> >>> While your proposed approach is rather clean, it carries one drawback,
> >>> which is the lack of type information, with all its consequences.
>

<snip, need to convert domain-types to/from strings/doubles/QVariant on QML
side and C++ side>

PRO:
*- Can data-clean/input-validate on either C++ or QML side, can add more
custom validators in different places
*- ?More fine-grain control at data-input/UI separate from back-end

CON:
*- Rules for validation now separate from domain-specific type
*- Property misspell no longer compile-caught, instead run-caught (if
validated input)
*- Must invest in this "adapter-layer" that may ultimately be merely a
"pass-through", can be expensive to implement for big systems (many types),
or to value-copy/transform state for some rich types

>> Also once you grab your data back from the QVariantMap in C++ in the
> controller you must use an accessor like .toString() etc to cast the
> QVariant to a known type, and that brings back your type checking on the
> C++ side.
>

For us, these are often "lossy" and very "stale" operations (converting
to/from string, double, etc. from our internal types. Dealing with hardware
and constantly changing values, it would be nice to reference the
"real-item" directly rather than establish an adapter layer that is (by
definition) lossy-and-stale for our use.

<snip>,

> > A other problem i can see is the Code-Completion which you can't get for
> > QVariantMap because it's a variable type which can store anything in any
> > format. I think for Projects where the QML Developers know the C++
> > Developers this works, but in larger Projects like having a API for
> > 3rdParties i think QVariantMaps doesn't work and we need to invest some
> > time to make a proper solution.
>

Agree that QVariantMap drops type information.  Agree that loss of type
information can be an increasingly important issue in larger systems with
more domain types (because those types established rules/behaviors in the
system, and that's more important in large systems).


> Definitely, I’m not arguing against a better way / ‘proper solution’.  By
> all means lets work on that please.  I was only addressing the concern that
> you can’t use QML at all when working with large numbers of non QObject
> derived domain specific data objects.  In that respect I’d say we’re quite
> better of, at least in our project, for using QtQuick/QML over widgets.
>

I think there are two topics here:

(1) Deep/rich/many domain-specific C++ types (or their state/properties)
need to somehow be made "available" to QML through a reasonable mechanism
that scales for large C++ systems.  QVariantMap is one suggestion that
works for some systems.  IMHO, the loss of type-information is a
deal-breaker for large systems (see below), although I concede that some
people have a back-end to front-end transform, API collapse, or system
workflow where this would work.

(2) QtQuick/QML is preferred over widgets.  We agree; I realize some people
aren't sure, or currently disagree for a couple reasons.

IMHO using "QVariantMap" is really good when there is a strong API
"collapse" or "transform" from the very-deep-back-end-system and the
"relatively-flat" set of properties that should be exposed to the UI/QML.
 However, some systems are "rich", and this "deep-nested-type-state" is
important (even through to the interface).  It becomes important to
*maintain* that "nesting", and in that case, producing the
nested-QVariantMap may be expensive (and it might be big), and might be
especially difficult to describe in a granular form that supports
transactions at different levels of interface update.

Further, for our types, we have MANY "derived-properties".  From one (or a
very small number) of "data-members", we may have MANY "properties" that
are "available", but these are computed-on-the-fly.  I don't want to
produce those to populate a QVariantMap if they are not really needed.
 Some hardware-reads are really expensive.

Others have touched on these, but to summarize:

(a) creation of a "QVariantMap" (or similar value-semantics) approaches are
investing in an "adapter layer" (I'd prefer to not write a bunch of
"toQVariant()/fromQVariant()" in my zillions of C++ classes, and it's hard
to guess the level-of-granularity to support transaction-updates at varying
levels of interface update.)

(b) the "values" populated in a "QVariantMap" are immediately "stale" and
"lossy" in our system (we drive hardware and embedded systems, or systems
with lots of dynamic updates and would prefer to reference the,
"real-C++-object-thing")

(c) many of our "property-values" are functionally/dynamically computed,
and should not be computed unless explicitly "needed".  (An example is a
class with one data member, which *is* a property, but also provides four
other "properties" that may be computed from that one data-member; all
"five-properties" should not be populated into the QVariantMap unless they
are really needed.)

In contrast, I could live with something in QML like a
"QmlSmartPtr<MyCppType>" that might own-or-reference the "MyCppType"
instance, if I can describe for QML the five "QML-properties" that are
available from that one "MyCppType" instance.  I need the *real* C++
function (property get/set) to be available in QML.

Summary:

(1)  Kudos to Roland for properly entitling this thread for, "QML Value
Types"

(2) IMHO, QML is the way-to-go

(3) This "value-type" is a topic-for-discussion (which should probably be
followed by one or two "recommended-best-practice(s)")

(4) Supporting "user-defined-C++-values" seems like an important thing for
large/legacy C++ code bases.

(5) QVariantMap is a reasonable solution for some systems, but not for my
system.

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