Data model and variables, which can be null

[szopeno]

Hi,
i'm just playing with RmlUi because it's fun. Let's say we have a Location, and there is std::vector of teams which may be on that location. Since the list could be large, instead of making data-for (which would have to be nested inside data-for for map's Location elements), i wanted to show only the first element of the vector, if the vector's size is larger than zero.

Something like this:

<img data-if="place.teams.size > 0 && !place.teams[0].is_moving" data-attr-src="place.teams[0].portrait"/>
This, however produces warnings:

Data array index out of bounds.
Could not get value from data variable 'choices.location.places[2].teams[0].portrait

Soo.. any ideas, how to avoid that? Either using some functionality of Rml I am not aware of, or maybe suggesting different way of doing it? The first would be preferable, as i've keep encountering the same situation, where the object may have nullptr child, and if the child is not nullptr, i would want to render it.

The error is not about places[2], because its inside data-for place : places

BTW it would be very nice having something like

<div data-assert="!null( variable" data-other-expressions>

where "data-other-expressions" within that particular element would not be checked/executed and element would not be rendered if data-assert would fail. Or any other way which would allow to tell "this variable may be null"

[mikke89]

Hi,

I think it's a very good question, there has been some similar feedback and discussion around these things before. And I can see that it's a relatively common scenario.

There are different opinions on which situations should actually be warned about and not. One approach is just to simply filter and ignore the warnings. It is actually somewhat justifiable, as the warnings shouldn't really cause major issues, like crashes. Although it's not entirely defined how it ends up behaving.

I do find your suggestion with an "execution" check quite interesting. However, I wonder if turning off synchronization like that goes a bit against the data binding philosophy, the evaluated RML would end up depending on its history. And requiring manual intervention makes it a bit of an advanced feature, where other users might decide to live with the warnings for seemingly the same behavior.

One approach that's been discussed earlier is the idea of a null type. So instead of an out-of-bounds warning, we could perhaps return a null value. Then you can further evaluate that how you want. Here is some related discussion, and an old commit. I don't remember why it didn't end up in master, maybe it was just never finished up.

[szopeno]

What about lazy evaluation e.g. for ternary ?: operator? From my experiments it seems all expressions are evaluated eagerly. Am i wrong? Seems to me that in X?Y:Z all expressions X, Y, Z are evaluated, but then only Y or Z are returned. Runtime lazy evaluation ( evaluate X, if it's true, evaluate Y, forget Z) would provide at least temporary workaround.

BTW ive encountered crashes too. E..g i would love to have something like data-if="location!=nullptr && location.id == choice.id" - currently it crashes the program if location is null. I made several workarounds (like creating façade classes which are never null), i could just implement CustomElement and check everything inside but... it would be so easier if I could do that with just rml

[rminderhoud]

@szopeno You are correct both sides of the ternary are evaluated which is an issue we ran into. We have a fix for this in our fork of RmlUI which we can upstream if there is interest

[mikke89]

Oh, right. That's an even better fix! Or at least complementary to any other changes we want to make. I didn't realize this was the case before this thread.

Thanks a lot for the PR @rminderhoud (#740 for reference)!

As for the crash mentioned, yeah I don't remember exactly right now, but believe we expect users to provide valid pointers. That commit I linked above should resolve this though. I'm not sure if we short circuit boolean expressions either right now, that might be worth looking into as well.