18.3. Support for more date formats

If you need to use a date format that can not be expressed by the subpatterns mentioned above ('dd','MM','yyyy'), you have to some more work:

  1. Construct a date pattern for your desired format using the possibilities documented in class java.text.SimpleDateFormat. Set this format as global date format inside dbforms config file.

  2. Construct a date pattern for the same format using the calendar's date patterns. Have a look at the comments inside file calendar.js for details. This step can be neccessary, because some subpatterns have different meanings in both worlds. The new pattern for the calendar can be set by using the attribute jsCalendarDatePattern inside tag dateField:

    Here is an example:

    Inside dbforms-config.xml you have:

    <date-format>yyyy-M-d</date-format>

    Inside the JSP you set the corresponding calendar format:

                         <
                         db:dateField
                         fieldName="birthdate" jsCalendarDateFormat="yyyy-mm-dd" />>
    
                      

    Another example:

    Inside dbforms-config.xml you have:

    <date-format>MMM dd',' yyyy</date-format>

    Then inside the JSP you set:

                         <
                         db:dateField
                         fieldName="birthdate" jsCalendarDateFormat="Mon DD, yyyy" />
                      

  3. The calendar has a build in parsing routine that is able to parse the simple patterns mentioned above. If the date pattern is different, it just uses the build in constructor for a JavaScript date object. If your date pattern is not understood by the calendar, you may experience that the calendar always starts up with the current date, not with with date that was set in the form field. It might then be neccessary to add some custom parsing code into the file calendar.js.

    Normally the JavaScript calendar trys to use the locale of the used browser for names of weekdays and months. But if that might lead to problems when you use patterns including textual representations of dates like in 'May 08, 2002'. A calendar running e.g. on a browser in Germany would set this date as 'Mai 08, 2002' and you would get an error when trying to save this value. That's why the calendar automatically will use English names if the date pattern is not a simple one, so that the result date given back to dbforms hopefully will be correctly understood and parsed. If the default locale of your server is not an English one, it would currently be the best to avoid date patterns containing textual representations of months.