We're missing today on a textfield (as an example) what kind of object the value set/bounded comes from. If the expression used corresponds to an object that has an ObjectDescriptor and an identifiable matching propertyDescriptor, the control should be able to get the corresponding converter, validator, even placeholder from it.
Or, a different set of API could be added for that use case if it were too difficult to analyze the frb expression to get a conclusive answer. Instead of "value", it could be:
data property: the object
value expression: the property edited by the control.
To be analyzed further. This would significantly reduce amount of work needed, and errors.
With the type of the value in a property, and the "native" type to a control, such as "String" for text-inputs, we would be able to automatically identify and find if available a property_type-to-string-converter to be used.
We're missing today on a textfield (as an example) what kind of object the value set/bounded comes from. If the expression used corresponds to an object that has an ObjectDescriptor and an identifiable matching propertyDescriptor, the control should be able to get the corresponding converter, validator, even placeholder from it.
Or, a different set of API could be added for that use case if it were too difficult to analyze the frb expression to get a conclusive answer. Instead of "value", it could be:
To be analyzed further. This would significantly reduce amount of work needed, and errors.
With the type of the value in a property, and the "native" type to a control, such as "String" for text-inputs, we would be able to automatically identify and find if available a property_type-to-string-converter to be used.