Announcement Announcement Module
Collapse
No announcement yet.
InitBinder & CustomPropertyEditors with null values... Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • InitBinder & CustomPropertyEditors with null values...

    We've been trying to create a custom property editor for a Float value to allow display of nulls as "N/A" and conversion of any non-float to null on set. The code for the custom editor is included below.

    After some investigation however it looks as though the getAsText method will never be called when the value of the property is null. This can be seen in the getFieldValue method of org.springframework.validation.BindException. Should the check for value == null be present? It seems to me the check for a binding failure should be enough..

    If this can be removed how likely it'll be in the next release? To me it makes sense that if you have a custom property editor you want to handle all values, not just the non-null ones.

    BindException.getFieldValue
    Code:
    	public Object getFieldValue(String field) {
    		field = fixedField(field);
    		FieldError fe = getFieldError(field);
    		// use rejected value in case of error, current bean property value else
    		Object value = (fe != null) ? fe.getRejectedValue() : getBeanWrapper().getPropertyValue(field);
    		// apply custom editor, but not on binding failures like type mismatches
    		if (value != null && (fe == null || !fe.isBindingFailure())) {
    			PropertyEditor customEditor = getBeanWrapper().findCustomEditor(null, field);
    			if (customEditor != null) {
    				customEditor.setValue(value);
    				return customEditor.getAsText();
    			}
    		}
    		return value;
    	}

    Custom Editor:
    Code:
    package emt.application;
    
    import java.beans.PropertyEditorSupport;
    
    public class FloatCustomPropertyEditor extends PropertyEditorSupport
    {
    	public String getAsText()
    	{
    		System.out.println("getAsText()");
    
    		if (getValue() == null)
    		{
    			return "N/A";
    		}
    		else
    		{
    			return getValue().toString();
    		}
    	}
    
    	public void setAsText(String text) throws IllegalArgumentException
    	{
    		System.out.println("setAsText(" + text + ")");
    
    		try
    		{
    			Float maxRunningSpread = new Float(text);
    			setValue(maxRunningSpread);
    		}
    		catch (NumberFormatException e)
    		{
    			setValue(null);
    		}
    	}
    }

  • #2
    I think this is a reasonable request. I've inserted a JIRA issue. Since 1.1 final is almost finished, I don't think it'll be included, but I've asked Juergen to have a look at it.

    http://opensource.atlassian.com/proj...browse/SPR-273

    Alef

    Comment


    • #3
      Indeed, that can be considered a bug: PropertyEditors are supposed to apply to null values too. I've just fixed BindException accordingly.

      Juergen

      Comment


      • #4
        Excellent means we'll be able to pull the form related getters & setters from our beans again. Is it too much to hope this may make it into the coming release??

        Thanks for the prompt response, glad it wasn't just me misunderstanding PropertyEditors!

        Comment


        • #5
          It would be nice if this also worked in the other direction: giving a PropertyEditor a chance to translate null values to some alternative representation.

          A simple use case would be the current CustomCollectionEditor: translating null to an empty java.util.Set of java.util.List implementation would make sense in many scenario's.

          For instance, take a web form listing all application roles, both those assigned to a given user, and those available for addition. It's typical to present such an interface using either a select (multiple=true), or a set of checkboxes. It's possible to use CustomCollectionEditor or variations to bind directly to domain objects (instances of some Role class).

          This leads to the problem of dealing with submits with an empty selection: the usual solution is to use the "field marker" support in WebDataBinder. However, WebDataBinder produces a property value with a null value.

          In some situations, a valid domain representation of null may by an empty Collection, an empty array, or perhaps a model-specific Null Object.

          Comment

          Working...
          X