Uploaded image for project: 'Grails'
  1. Grails
  2. GRAILS-7287

The i18n message codes used by scaffolding and validation for property names differ from those used by spring databinding


    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.3.7
    • Fix Version/s: None
    • Component/s: Scaffolding
    • Labels:


      Description copied from this thread: http://grails.1312388.n4.nabble.com/i18n-message-codes-property-names-and-spring-databinding-td3034921.html (0 replies as of 2011-02-18)

      Let's say I have a property with a camel case name like "dateOfBirth" on a domain model "com.mycompany.User"

      This property should have a user presentable name in the messages file. What code should I use?

      There are 3 cases I can think of which will need to fetch the message for this field (are there any others?)

      == 1. Field labels in the UI

      e.g. the scaffolding for field labels: (<label>Date of Birth</label>)


      The scaffolding tries only one code:

      • user.dateOfBirth.label

      == 2. Validation messages

      e.g. if you set "default.null.message" to "You must specify a

      {0}" then you get "You must specify a Date of Birth"


      This will try the following codes:
      * com.mycompany.User.dateOfBirth.label
      * user.dateOfBirth.label

      == 3. Databinding messages

      e.g. if you set "typeMismatch.java.util.Date" to "The {0}

      must be a valid date" then you get "The Date of Birth must be a valid date"


      This will try the following codes:

      • com.mycompany.User.dateOfBirth
      • dateOfBirth

      I can change the codes used in (1) by not using the scaffolding, but AFAICS I have control over the codes used by (2) or (3).

      Given that there are no codes which are in all 3 lists, does that mean that I have to define all property name messages twice?

      Incidentally, it seems to me that the root of the problem is the Grails message suffix ".label", which isn't used in Spring. Maybe the best fix would be to drop that from Grails code. Perhaps something to consider for Grails 2.0?


        There are no comments yet on this issue.


          • Assignee:
          • Votes:
            1 Vote for this issue
            1 Start watching this issue


            • Created:
              Last Reviewed: