On Apr 25, 2014, at 7:28 AM, Dominik Holland <dominik.holl...@pelagicore.com> wrote:
> > 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. > Ah yes we don’t use QDoc. I can see how auto documentation generation could be improved. (Currently we use literate coffeescript for the views and are setting up something similar on the c++ side. Admittedly a fairly obscure approach for most.) > 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. > I’m not sure what you mean, are you talking about a particular IDE? I would think any custom data type weather it’s c++ or javascript would have a similar issue within an IDE. Personally I use sublime text and from time to time I do create code completion snippets for custom objects, but no more so for javascript data types than c++ ones. I don’t think I understand what you mean though. 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. j > 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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
