On Thu, Apr 22, 2021 at 7:19 PM Giuseppe D'Angelo via Interest < interest@qt-project.org> wrote:
> You should create a C++ layer (call it a "presentation" layer) that sits > between your (possibly non-Qt) business logic and the UI. That layer > contains stuff like item models, QObjects that expose the relevant > business logic APIs, type wrappers, and so on. > Registering a struct/data class with the meta type system and/or marshaling it over QVariant, just so it can be visible in QML isn't that. Or things as natural (with C++) as having the UI raise some encapsulated piece of data in a signal (say some struct, say QColor or QVector3D) which the backend responds to isn't it either. As a matter of fact, how do you tie your existing backend to QML? Say we have this nice encapsulated UI that's completely decoupled from the business logic, how do I tie a specific object from the Quick scene and connect the notifications back to C++? I can't do it from the business logic (i.e. controller side), I have to expose the backend to the QML engine and do it from there, am I wrong? Basically you say it's fine that the UI drives the controller (incl. object creation)? We can agree on the principles, gladly, but this is really a gross oversimplification of the problem. While building this layering may be super tedious (YMMV), in the long > run, it makes your application more robust, not less. The fact that QML > _forces_ you to have this stuff becomes somehow a good thing. > Forces you? Do you mean, perhaps, that JS is somehow not supported, or maybe that Component.createObject is somehow hidden and/or inaccessible? On widgets, well, raise your hand if you didn't at least once connect a > QPushButton to a slot declared in the widget that contains the button, > and perform some business logic from there (yay business logic in the UI!). > Yes, it is done, and not without an honorable mention of the documentation, where the view-controller idiom is used extensively. But then, raise your hand if you at least once didn't use an `if` (or some other JS piece of code) in a QML file. I can pull out for you numerous cases of it being done, probably too numerous to count even in the examples. Shooting yourself in the foot is not restricted to one language or another, nor to the technological solution in use is my point. You can make a holy mess of any piece of code on any language you choose, and QML certainly doesn't force you to do anything you don't *really want to*. In other words, being "entirely" in C++ has also its downsides. > Most certainly. One of the major downsides is it being much more complex and unforgiving, which doesn't necessarily mean it's better.
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
