Add generic support for "reverse" null representations

[Legioth]

Binding.withNullRepresentation is currently intended for "protecting" the presentation side of the binding from null values originating from the model side. There are also some cases where protection is needed in the other direction.

One typical example is to deal with the null value that you get from a StringToIntegerConverter if the field value is "". Storing a null in the model would generally be the expected case here, but that isn't possible if the model property is int instead of Integer.

One alternative here is to allow configuring StringToIntegerConverter to return some other value instead of null when the presentation value is "", but that approach has some ambiguity challenges that would need to be considered separately.

In either case, it would also be good to have a solution directly in Binder that would work regardless of any used converter. For this, I would propose a two-argument overload of withNullRepresentation that is also configured with an enum that defines in which direction the null representation conversions should go. The current one-argument overload would be retained to use the current approach of protecting against null values from the model. For the enum name, I'd suggest NullOrigin and the supported values would be MODEL and PRESENTATION.

This would mean that the case with a TextField bound to an int property could be implemented like this:

myBinder.forField(myTextField)
  .withConverter(new StringToIntegerConverter())
  .withNullRepresentation(0, NullOrigin.PRESENTATION)
  .bind("intProperty");

Instead of the enum, a separate method name could also be considered if anyone would have a good name suggestion.

• withModelNullRepresentation doesn't make the direction clear: Does it define how to present a null value from the model, or a null value going to the model?
• withNullRepresentationToModel makes the direction clear, but is quite verbose. Should the other direction be withNullRepresentation, withNullRepresentationFromModel, or withNullRepresentationToPresentation?
• withReverseNullRepresentation is clear if you know that withNullRepresentation is the default, but the name is again quite ugly.

[Legioth]

Actually, my example wouldn't even work since the reverse null representation would cause null to be passed straight through the converter and into TextField.setValue, which would throw. It would thus also need a non-reverse withNullRepresentation("") on the presentation side of the converter to work.

Another slightly related realisation is that StringToIntegerConverter is currently slightly asymmetric. "" is converted to null, but in the opposite direction, null is converted to null instead of "".

[Legioth]

To further complicate things, there are some cases where the default value should be shown in the text field and some cases where the field should be empty instead. In general, a default value of -1 shouldn't be shown, but a default value of 0 should sometimes be shown and sometimes not.

These two cases could be handled with the suggested generic binder API, but it won't be very obvious.

// "0" and "" are set as 0, 0 is shown as "0"
myBinder.forField(myTextField)
  .withNullRepresentation("0")
  .withConverter(new StringToIntegerConverter())
  .withNullRepresentation(0, NullOrigin.PRESENTATION)
  .bind("intProperty");

// "-1" and "" are set as -1, -1 is shown as ""
myBinder.forField(myTextField)
  .withNullRepresentation("")
  .withConverter(new StringToIntegerConverter())
  .withNullRepresentation(-1, NullOrigin.PRESENTATION)
  .bind("intProperty");

Both cases could also be supported by a StrintToIntegerConverter(String defaultString, Integer defaultInteger) constructor. The logic would be that defaultString, "" and null are all converted to defaultInteger, whereas defaultInteger and null are both converted to defaultString. With the no-args constructor, both parameters would be null to replicate the default behavior where "" and null are converted to null in one direction and null is converted to null in the other direction.

With this functionality, the examples would look like this.

// "0" and "" are set as 0, 0 is shown as "0"
myBinder.forField(myTextField)
  .withConverter(new StringToIntegerConverter("0", 0))
  .bind("intProperty");

// "-1" and "" are set as -1, -1 is shown as ""
myBinder.forField(myTextField)
  .withConverter(new StringToIntegerConverter("", -1))
  .bind("intProperty");

This is a very compact representation, but it's not clear whether it would be easily understood by someone reading the code.

We could also consider a StringToIntegerConverter(Integer defaultValue) constructor that would map to StringToIntegerConverter(defaultValue, Objects.toString(defaultValue, null)), thus allowing new StringToIntegerConverter("0", 0) to be written as new StringToIntegerConverer(0).

Yet another approach could be a generic binder feature that simply replaces one value for another:

// "0" and "" are set as 0, 0 is shown as "0"
myBinder.forField(myTextField)
  .withReplacementToModel("", "0") // Only applies in one direction to avoid showing "" when the model value is 0
  .withConverter(new StringToIntegerConverter())
  .bind("intProperty");

// "-1" and "" are set as -1, -1 is shown as ""
myBinder.forField(myTextField)
  .withReplacement("", "-1")
  .withConverter(new StringToIntegerConverter())
  .bind("intProperty");

With this logic, withNullRepresentation(value) is just a shorthand for withReplacement(value, null) and the previously suggested withNullRepresentation(value, NullOrigin.PRESENTATION) could be expressed more compactly as withReplacement(null, value).

This mechanism could also be used to easily replicate the default null handling logic in cases where a converter is explicitly added:

myBinder.forField(myTextField)
  .withReplacementToPresentation("", null)
  .withConverter(someConverter)
  .bind("someProperty");

[Legioth]

Decided that we won't do anything else about this right now other than making it possible to configure what value the converter will use when converting "" (#8506). The other ideas suggested in this issue are still relevant and could be considered as a future enhancement.

[stale]

A lot of tickets have been left hanging in the issue tracker through the years. Some of them are still relevant, some of them have been fixed a long time ago and some are no longer valid. To get a better look on what is important and still relevant, we are closing old tickets which have not been touched in a long time. No further work will be done on this ticket. If the ticket seems to be still actual, please verify the problem existence over latest framework version and then open a new ticket in vaadin/framework with all the suitable information.