Formatted "text-field" property setter #13358
Conversation
LukasPaczos
force-pushed
the
lp-13173-formatted-plain-text-getter
branch
from
16c8a66
to
b5f2eba
Compare
LukasPaczos
force-pushed
the
lp-13172-formatted-property-setter
branch
from
111b17c
to
80e6cbc
Compare
LukasPaczos
changed the base branch from
lp-13173-formatted-plain-text-getter
to
master
LukasPaczos
force-pushed
the
lp-13172-formatted-property-setter
branch
2 times, most recently
from
b91aa6c
to
66d3d3b
Compare
|
Tests are finally fixed, this one is ready for a review @tobrun @ChrisLoer. |
There was a problem hiding this comment.
🎉 This looks good! But it does concern me a little that we have a new array-based serialization format for Formatted. I don't actually see a problem with it, it just seems confusing that sometimes a Formatted will be represented as:
['format', 'foo', { 'font-scale': 1.5 }, 'bar', { 'font-scale': 0.5 }]
And another time it'll be represented as:
[['foo', { 'font-scale': 1.5 }], ['bar', { 'font-scale': 0.5 }]]
| return Formatted(result->c_str()); | ||
| } else { | ||
| error.message = "Not supported Formatted type property."; |
There was a problem hiding this comment.
Maybe "Formatted must be plain string or array type"?
|
True, the first one represents an expression, the other represents a constant value. If we were to represent the consant on the Java side using the same array as the expression, it would have gone through the coercion proccess and be evaluated to a constant as well, but since it's a new base type, distinguishing the paths and types seems clearer to me in this specific case. |
LukasPaczos
force-pushed
the
lp-13172-formatted-property-setter
branch
from
66d3d3b
to
44a87fd
Compare
Closes #13172.
Exposes
PropertyFactory#textField(Formatted)property setter. A JavaFormattedobject is passed as an array that's converted to a coreFormattedobject.