Spring MVC and an empty combo box

[Roel De Nijs]

I have 2 combo boxes: the first one contains types, the second one contains subtypes. When user selects a new type, the 2nd combo is refreshed with the subtypes of the selected types. When user submits the form, both chosen values (type and subtype) are bound to the backing bean, so that's working fine.

But sometimes it could happen that a type does not have any subtypes, so the 2nd combo is empty and when the form is submitted only the chosen type is bound to the backing bean, the subtype is not bound (and thus the backing bean is holding the formerly chosen subtype.

Is this the normal (and expected) behavior using Spring 3.0 @MVC?

For now I have this work-around: I add an extra option ("Please select one") to the 2nd combo and when a type has no subtypes the value of this extra option is bound to the backing bean. Is this approach the best thing you can do?

[Nathan Pruett]

I believe this is expected behavior - what's happening is that no "name=value" parameter is being sent through the request for that property, so when Spring goes to bind the parameters to the model, that property gets skipped.
One way to fix it is to add a "default" value like you did, so there's always a "name=value" parameter sent for that property.

There are a couple of things on the controller side to address this if you don't like the "default form value" approach -

You can make a custom Converter class for your model object that loads the model and then always clears the potentially-empty property. Register this custom Converter in an @initBinder method in your controller. This works because it clears the value before the request parameters are bound to the model - so if the value is present, it's set, if it's not, it's been cleared.

Instead of always loading the model right away, you can create a brand new instance of your class each time in your controller and have the request values bound to it, then later load the real object you want and "manually" set the properties from the brand new form backing object.

[Roel De Nijs]

Thanks for the swift reply!

I'm ok with the approach of having a default combo value, it obliges the user to really make a choice and makes her think (instead of just going with some form default because that's easy and quick). So I'll probably stick to this one.

But what do you mean with the 1st alternative? I guess you are referring to the DataBinder.registerCustomEditor(...) method but I don't see how that could give me the desired behavior. But that's maybe because I'm completely new to Spring MVC. I understand how you can use this approach to trim all strings (using StringTrimmerEditor) or to have a custom editor to convert Strings into Color-objects, but don't get how it could be helpful for my situation (I don't have a speific class for these types and subtypes, just plain strings)