Potential Bug: Databinding For + Select

[Dakror]

I've just run into an interesting situation that was quite unexpected. Consider the following layout

<select data-attr-value="model.value" data-event-change="model.onChange()">
    <option data-for="it : model.items" data-attr-value="it.value">{{ it.text }}</option>
</select>

I'm using attr-value + event-change instead of data-value to be able to implement custom logic when the value changes inside the listener instead of direct data coupling.

The issue that arose is the following:

When booting up the document and setting the initial value for the select value, the correct option cannot be selected.
Due to the order of the databinding statement in the hierarchy, the attr-value data view is evaluated before the data-for generates all the option children.
Thus the drop down widget only sees a single option (the data-for prototype) instead of the finished list.

The workaround is to use data-attrif-selected on each option instead of attr-value on the select, but i feel like this is quite unexpected and both ways should work.

I guess the data-for being a structural data binding element should be evaluated before? What do you think?

[mikke89]

Hm, right, I see. Currently, we're evaluating data views in tree depth order first. Here is the reasoning for that:

RmlUi/Source/Core/DataView.cpp

Lines 130 to 132 in 70d0d5e

	// Sort by the element's depth in the document tree so that any structural changes due to a changed variable are reflected in the element's
	// children. Eg. the 'data-for' view will remove children if any of its data variable array size is reduced.
	std::sort(dirty_views.begin(), dirty_views.end(), [](auto&& left, auto&& right) { return left->GetSortOrder() < right->GetSortOrder(); });

I agree that it would be nice if we could make this work. Evaluating data-for first generally seems like a good idea, but they themselves need to be updated in tree depth order I guess? We need to figure out the exact rules and ensure things work out as expected, and ideally we can make them deterministic.

It might be as simple as adding a large enough sort order bias to the data-for view.