Am 25.04.14 15:05, schrieb Joshua Kolden: > > On Apr 25, 2014, at 3:51 AM, Alberto Mardegan <ma...@users.sourceforge.net> > wrote: > >> On 04/24/2014 03:11 PM, Joshua Kolden wrote: >> [...] >>> We have a solution that works very well for us using QVariantMaps and an >>> MVC pattern / strong separation between data objects and view. It >>> appears to me that most people are having this issue because it’s not >>> common to use MVC with QtWidgets. But you can easily expose complex >>> data structures to QtQuick without subclassing QObject via QVariantMaps. >> [...] >> >> While your proposed approach is rather clean, it carries one drawback, >> which is the lack of type information, with all its consequences. >> >> For instance, I would like to have a GeoPoint type with "latitude" and >> "longitude" properties; if I exposed it as a QVariantMap, I wouldn't be >> able to prevent the QML code from doing stuff like: >> p.latitude = 60 >> p.longitde = 10 // note the typo >> > Actually you can (at least at runtime), although we don’t. In the > application runtime we use explicit input validation for user input in the > view as apposed to relying on compiler errors. This gives us much finer > grain control over what constitutes valid data, as apposed to only validating > type and existence as compilers do. Also our GUI development is in real time > on top of the running application (do that with widgets), so variable typos > are immediately obvious. > > If as I’ve described these data types are QML properties then onChanged is > signaled, so you can easily run any type of validator (in javascript or c++). > This includes listing all keys in the QVarianMap for `eatra` values that > shouldn't be there, missing values, type or range invalidations etc. > > 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. > However, what you’ve described is a coding error, as apposed to a user input > error, we don’t check this in application code at all nor do we rely on the > compiler to catch everything as this is the domain of the test sweet. > > j
We are also currently using QVariantMaps in a Project and beside having more work to validate the Data which comes in the Controller classes instead of validating the input in the QmlType classes itself it also has some other problems at least for us. We are using QDoc to generate QML Documentation for our Interfaces and instead of describing all the available properties in the QmlType you need to document the properties of the QVariantMap in the function. Sure i think there are ways to some kind of Fake QmlType page and document the properties (which is a QVariantMap in the real world) but i don't think it's a proper solution. 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. Dominik > >> Ciao, >> Alberto >> >> -- >> http://blog.mardy.it <- geek in un lingua international! >> _______________________________________________ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development