Explain how values are converted when updating a data view #35
Conversation
| When updating data views including attribute, style, rml and text, the value is converted to a string. Consult `Source/Core/DataViewDefault.cpp` to know how each data view converts the value, and the specializations of templated class `TypeConverter` to know how exactly the conversion is done. A case to keep in mind is boolean value is converted to strings `"0"` or `"1"`, so if you have an element like | ||
|
|
||
| ```html | ||
| <div data-attr-foo="user_data"></div> | ||
| ``` | ||
|
|
||
| where the value `user_data` is bind to a boolean value, the RCSS selector on it should compare the value to `"0"` or `"1"`, for example `div[foo=1]`. |
There was a problem hiding this comment.
First of all, thanks for contributing again to the documentation!
I think it's a nice clarification, and I better understand the initial confusion too. Some parts feel perhaps a bit too specific here, but with some rephrasing/generalizing a bit, it should work well. I also want to avoid pointing to the source code from the documentation. Here is my suggestion:
When data views are updated, their data expressions are evaluated and converted to strings before being applied to the document. Any type conversion to string is done using RmlUi's built-in
TypeConverterutilities. One aspect of this conversion is that booleans are converted to strings"0"or"1". Consider an element<div data-attr-foo="user_data"></div>where the value
user_datais bound to a C++ variablebool user_data = true. The element's attribute will be set tofoo="1"{:.attr}. Any associated RCSS attribute selector should use the same representation of the value, i.e.div[foo=1].
There was a problem hiding this comment.
evaluated and converted to strings
I am not sure about this. For example, DataViewIf::Update seems to interpret the expression as bool. So I picked 4 data views that I confirmed by the source code that converts the expression to strings. Is this appropriate?
There was a problem hiding this comment.
Good point, that's true.
As I understand it, the main essence here is that anytime different types are compared, they are done so using our type conversion utilities. And particularly, the bool<->string conversion this implies. So listing the exact data views that convert to string isn't really essential to convey this message, as I understand it. How about:
When data views are updated, their data expressions are evaluated and applied to the document using any necessary type conversion. Type conversion is done using RmlUi's built-in [...]
To expand a bit, considering the attr view, we might just as well have set the bool type from the data expression directly on the attribute. In that case, we would still have had to use the same div[foo=1] selector, since that is how our type conversion works. The conversion would just happen in another location.
|
I hope this is clearer now. I also reviewed all the subsections in the page, and added type conversion rules where I feel it may needs a bit of clarification (76490da). Maybe this is unnecessary, though. |
|
I think perhaps the notes about conversion to String are a bit noisy, and more of an implementation detail - in the sense that we could change this without actually affecting usage in any way, I believe. Other than that, it looks good to me. |
This reverts commit 76490da.
|
Reverted that commit. Hope it looks good now ;) |
|
Perfect, thanks a lot for the PR and following up on it! |
I mentioned this problem in mikke89/RmlUi#670 (comment). I think I've understand a bit of it, so here's a PR that explains this to new users. It may still be incomplete, and I'm looking forward to your suggestions.