Skip to main content

AbstractBinding.convertToModelType

4 replies [Last post]
Anonymous

I've just been stung by the behaviour of this method, and would like to open a
discussion.

I have a JForm, with address fields bound to my model

JavaBeanDataModel addressModel = new JavaBeanDataModel(MutableAddress.class,
mutableAddress);
MetaData metadata = addressModel.getMetaData("city");
metadata.setLabel("City");
form.bind(addressModel , "city");

Now the user deletes all the text in the City JTextField. So textField.getText()
== "".

Now tab away, and AbstractBinding.isValid() calls convertToModelType.

protected Object convertToModelType(Object componentValue)...
Object convertedValue = null;
// if the element is not required and the value is null, then it's
// okay to skip conversion
if (componentValue == null ||
(componentValue instanceof String && componentValue.equals(""))) {
return convertedValue;
}
....

componentValue is our "", which is then converted into null, so that my
MutableAddress gets setCity(null).

Should deleting the text set a null or an empty string? I can't help thinking
that most code would prefer the latter, with special case code to handle the
cases where I really want to remove the reference altogether. Or is there a
simple way to override this behaviour that I haven't spotted.

Duncan Mc^Gregor
The name rings a bell
www.oneeyedmen.com

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Kleopatra

Thinking aloud about it:

- basically handling of an "empty String" is a conversion matter. The
(default) converter reads the component value and converts it to a model
value, either pass it through as-is or convert it to a null

- what exactly should be regarded as an "empty String": could be a
length==0 String ("empty") or any String that can be trimmed to have a
length==0 String as result ("blank")

- once converted, validation steps in checking if null or empty is an
acceptable value in model space.

- metaData has a short-cut validation property "required" that's mapped
in AbstractBinding bowels into meaning !null or (String type and length > 0)

AbstractBinding has two problems:

a) the mapping of required is hidden in both checkRequired and
convertToModelType. For String types, that's equivalent to an implicit
conversion of an empty String to a null model value.

b) the short-cut validation doesn't follow the usual sequence of
processing (which is convert/validate on model type value). Instead it
does validate (==required on component value)/convert/validate on model
type value.

A way out might be to _always_ stick to the convert/validate sequence -
may involve implicit default converters/validators which will step in if
the client didn't provide any. Then the question boils down to
reasonable default behaviour: from the discussion it looks like
pass-through the empty would be the expected result for most? If so, how
to interpret a required (which is probably copied directly from backend
metaData)?

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Kleopatra

Hi Duncan,

>
> protected Object convertToModelType(Object componentValue)...
> Object convertedValue = null;
> // if the element is not required and the value is null, then it's
> // okay to skip conversion
> if (componentValue == null ||
> (componentValue instanceof String && componentValue.equals(""))) {
> return convertedValue;
> }
> ....
>
> componentValue is our "", which is then converted into null, so that my
> MutableAddress gets setCity(null).
>
> Should deleting the text set a null or an empty string? I can't help thinking
> that most code would prefer the latter, with special case code to handle the
> cases where I really want to remove the reference altogether. Or is there a
> simple way to override this behaviour that I haven't spotted.
>

Good point. I would expect the converter to decide about the behaviour -
but with the above implementation it's not called which looks like a bug
to me.

Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

rbair
Offline
Joined: 2003-07-08

> but with the above implementation it's not called
> which looks like a bug
> to me.

Agreed. Duncan, has a bug been filed for this? All, I guess there are two approaches. The first would be to define on the converter (as per Patricks suggestion) how to treat empty strings, the other would be to define it in meta-data. I think I'd rather define it in the converter as Patrick suggested.

Any opposed?

Thanks for bringing this up Duncan, much appreciated!

Richard

Patrick Wright

Duncan


> Should deleting the text set a null or an empty string? I can't help
> thinking
> that most code would prefer the latter, with special case code to handle
> the
> cases where I really want to remove the reference altogether. Or is there
> a
> simple way to override this behaviour that I haven't spotted.

IMO, this should be overridable, perhaps when the binding takes place?

form.bind(addressModel, city, EMPTY_STRING_AS_NULL);

or

form.bindNullable(addressModel, city);

with a default that empty string is "" if you use

form.bind(addressModel, city);

This is crucial also for handling cases where a relational DB is involved
where a) the column cannot be null, but the DB allows empty strings as
string values or b) the DB treats empty strings as null--in either case
the developer needs to know whether to match on a String value or if a
null might be there in the DB. Also important if the data field migrates
to other objects, tables, etc.

Just my 0.02!
Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net