Keyword final on StandardXmlValueBindingImpl [message #1239917] |
Wed, 05 February 2014 10:19  |
Eclipse User |
|
|
|
Is there a special reason why StandardXmlValueBindingImpl is final, while all other StandardXml*BindingImpl are not and can be extended for usage with @CustomXml*Binding .
I wanted to add a custom xml value binding that sets a 'null'-value in some cases, but right now I must copy the StandardXmlValueBindingImpl implementation, as it can not be extended.
|
|
|
|
Re: Keyword final on StandardXmlValueBindingImpl [message #1240095 is a reply to message #1240076] |
Wed, 05 February 2014 17:30   |
Eclipse User |
|
|
|
My use case is: Show an implicit default value in the presentation, that is derived dynamically. So when the value is empty, the property editor should show the default value according to some heuristic. A custom binding implementation could look like this:
public class ImplicitDefaultXmlValueBinding extends StandardXmlValueBindingImpl {
@Override
public String read() {
String value = super.read();
if (value != null && !value.equals(XmlUtil.EMPTY_STRING))
return value;
else
return defaultValue();
}
@Override
public void write(String value) {
final String defaultValue = defaultValue();
if (defaultValue.equals(value)) {
super.write(null);
} else {
super.write(value);
}
}
private String defaultValue() {
...
}
}
|
|
|
|
Re: Keyword final on StandardXmlValueBindingImpl [message #1240132 is a reply to message #1240102] |
Wed, 05 February 2014 19:26   |
Eclipse User |
|
|
|
Quote:My use case is: Show an implicit default value in the presentation, that is derived dynamically. So when the value is empty, the property editor should show the default value according to some heuristic.
For default values, you should use @DefaultValue or DefaultValueService instead of trying to solve this in the binding.
Quote:Is that use case above worth opening the enhancement request? The topic was discussed (offline) in https://bugs.eclipse.org/bugs/show_bug.cgi?id=421378 and then closed.
It all depends on the usecase as that would drive how the class is setup to be extended. For instance, StandardXmlListBindingImpl there is a protected initBindingMetadata() method so that subclasses can replace the standard behavior of reading annotations... etc.
|
|
|
Re: Keyword final on StandardXmlValueBindingImpl [message #1240417 is a reply to message #1240132] |
Thu, 06 February 2014 12:01   |
Eclipse User |
|
|
|
Another use-case:
We have several value properties of type Boolean. The value is bound against a Xml Attribute, which is optional in the Xml Schema. Now we want to remove the attribute in case of value 'false'.
The UI presentation is a checkbox that of course only has two states, checked & unchecked.
Right now the StandardXmlValueBinding always maps the unchecked state to false.
Also with @XmlValueBinding.mapExistanceToValue this can not be achieved.
@XmlValueBinding(path = "@MyBooleanAttribute", mapExistanceToValue = "true;")
results in
'checked':
<Element MyBooleanAttribute="">
'unchecked':
|
|
|
Re: Keyword final on StandardXmlValueBindingImpl [message #1240520 is a reply to message #1240417] |
Thu, 06 February 2014 17:11   |
Eclipse User |
|
|
|
The checkbox presentation actually has three state: default (either false or true depending on model), explicit false and explicit true. You can tell the difference between the default state and explicit state via the light bulb near the checkbox, which is only present if the state is explicit.
What you are talking about essentially removes explicit false state. I wouldn't advise doing this, but I do not see any harm in accommodating this. If extending StandardXmlValueBindingImpl would be helpful in this case, either re-open the existing enhancement request or open a new one.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03345 seconds