> > <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
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
