Announcement Announcement Module
No announcement yet.
Bind Tag question Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Bind Tag question

    Hi everyone,

    I never liked the way Spring handles custom error messages during binding. Declaring all non-String properties of an object in a message bundle to resolve them with a MessageCodesResolver, is in my opinion not a very elegant way to handle custom error messages.
    For small applications it may be allright, but when the application grows maintaining those message files becomes a cumbersome task.

    I think determining wether a value has the right format for binding should be done during validation. Accordingly, the message that tells the user about an error should be generated during validation.
    The way it is handled by spring feels to me like two different kinds of validation. The first one is the automatic type checking by spring and the
    second one is "semantic" validation based upon the specific needs of the
    application. For many applications it might be handy to leave type checking to the framework but for some a little bit more control is needed.
    For example when I want to allow empty fields for numbers (an empty field for an int attribute causes a binding error).

    Because binding occures in Spring before validation, there is no way to prevent Spring from automatically generating errors.

    I have developed a workaround to this problem(at least to me it feels like a problem ).
    I have created a SilentBindTag class that works exactly like the normal bind tag with one exception.
    It has an additonal "silent" attribute. If it is set in the
    JSP Page, no binding error messages will be created and therefore the responsibility of creating error messages is left to the validation process.

    How does it work?
    the SilentBindTag checks wether an error is a FieldError and if so, wether it is a binding failure ( with isBindingFailure())

    If it is a binding failure no error message will be added to the BindStatus object and therefore no error message will appear.

    Because the FieldError still exists(only the message was swallowed) the validator is able to evaluate the
    rejected value with getRejectedValue().

    in the JSP Page it looks like this:

    <spring:silentBind path="myObject.*" silent="true">
    <c:forEach items="${status.errorMessages}" var="error">
    <c:out value="${error}" /><br>

    Now my question:
    Is this a sensible approach for custom error messages
    or is there be a better way to do this (e.g. Struts XML validation stuff)?

    I am fairly new to Spring and to Java Web-Frameworks in general, so possibly this silentBind Tag is complete rubbish. I would be thankfull for some comments and suggestions:-)

    regards, Christian

  • #2
    More Information on This Topic?


    I am also trying to find an answer to the bind generating errors that I don't necessarily want. I'd like to have some fields be optional, and therefore, blank, empty, or null. Have you found out any further information about this issue?

    Can anyone else point me to information on how to address optional fields? I've been searching the forum and documentation and have come up empty, so far.



    • #3
      Maybe you want to take a look at the PropertyEditor, it will allow you to define what values will be accepted for binding and how to bind them. Validation and binding is for me two different things, binding, will set the property of your bean to the value entered by the user, and validation will validate this value according to your business rules.
      Binding errors are throwed when spring is unable to convert the string entered by the user to the type of the property associated. Indeed if the user enter a blank string, spring won't be able to convert it to an integer without the proper PropertyEditor. On a simpleFormController, you can add such propertyEditor, by overwritting the method : initBinder. Take a look at CustomDateEditor and CustomNumberEditor, which are handy PropertyEditor already package with spring.


      • #4


        Thanks for the info. In the interim, I found this information elsewhere and have implemented it. It seems to be just what I was looking for.