22/04/21 20:38, Konstantin Shegunov:
On Thu, Apr 22, 2021 at 7:19 PM Giuseppe D'Angelo via Interest
<interest@qt-project.org <mailto: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.
I think I'm missing some context: when you say "isn't that" or "isn't it", what "that"/"it" are you referring to?
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)?
"Controller" is an extremely overloaded word. Could you please clarify what design are you referring to?
I don't understand some of your points, like "UI that's completely decoupled from the business logic". What does this mean -- shouldn't the business logic be the one decoupled from the UI? Are you talking about UI testing (via a mock business implementation)?
We can agree on the principles, gladly, but this is really a gross oversimplification of the problem.
Sure it is! I said it myself, it's typically not just one magic do-it-all layer, but multiple layers. In those layers you
* adapt business logic datatypes into Qt datatypes; * write Qt models wrapping business logic datasets; * expose the relevant business logic in QObjects; * create custom UI components;* write state machines and what else is necessary to drive the UI based on the business logic state;
and so on. All/most of this gets done in C++. Some other bits may be done in QML, if it makes sense. The important message here is that such adaptation / UI logic layers do exist in any non trivial application, and the fact that from QML you just can't "just" reach into business logic, you need to jump through the language border, giving you a significant chance of making the integration more "clean".
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?
... I don't see how using JS magically allows you to call functions into your C++ business logic?
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 write FORTRAN in any language".The point I was trying to make is this: you need to write some degree of QML/C++ integration code to make the two worlds communicate. This, at least, gives you an excellent chance of clearly separating UI from business logic. That chance doesn't guarantee not doing a complete mess, but at least it's there.
(Then, as I said, you should also write most of your _UI logic_ itself in C++ as well. And now we have at least two layers. And so on an so forth.)
Now, am I saying that the C++/QML integration is absolutely perfect and you'll never write cleaner UI code? Of course not, there's still tons of shortcomings and annoyances that will make you say "sigh" and take shortcuts here and there.
My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
