On Thu, 30 Jun 2022 at 12:43, Federico Ferri
<federico.ferri...@gmail.com> wrote:
> My real-use case is too complex, but consider the simple scenario of a UI 
> control that features an array of whatever controls, say checkboxes, and 
> computes an aggregate property, i.e. a function of all the checkboxes states 
> f(repeater.itemAt(0).checked, repeater.itemAt(1).checked, ...).
> So I don't think this is violating the golden model-view separation rule. It 
> is a UI-only repeater, the Repeater's model it's just an integer, and could 
> be even constant. The aggregate property value (result of f()) is what is 
> exchanged with the business-logic model.
> But depending on the complexity of f(), not always it is possible to do it 
> without a for-loop iterating over the Repeater's delegates. Sometimes it is 
> possible to invert the logic, and have each delegate do its small bit of 
> computation, but that considerably increases the complexity, with respect to 
> the top-down for-loop solution.

That is basically what I would have recommended (and have done in the
past). Having the delegates update the information in a global object
/ property is quite reliable (well, as long as you ensure that what
they are doing is idempotent).

> Hence sometimes one would still prefer the for-loop approach. But if the 
> count property (which I believe it's also there to work together with the 
> .itemAt() method, and not just for showing a count to the user) was emitted 
> in a more sensible moment, one would not need redundant null-checks at what 
> .itemAt() returns.

If you absolutely have to do it, maybe schedule the actual calculation
to the next iteration of the event loop? Basically inside your
onXXXChanged handler, start a 0-interval single-shot Timer and do your
calculation there?

Shantanu Tushar

> An additional consideration: is the for-loop approach relying on signal 
> order? No, eventually there will be more property changes and the application 
> will settle to the final (correct) state.
> It's just that the current order of signals causes more transitory states, 
> some of which result in a JS error if we don't add those redundant 
> null-checks.
> --
> Federico Ferri
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interes
Interest mailing list

Reply via email to