Spring Roo
  1. Spring Roo
  2. ROO-204

datepicker semi-language dependent

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0.RC1
    • Fix Version/s: 1.0.0.RC2
    • Component/s: WEB MVC
    • Labels:
      None
    • Environment:
      Windowx XP language dutch (netherlands)

      Description

      Just ran clinic.roo script and try to add an owner.
      The datepicker widget doesn't if I set my windows locale to dutch (netherlands). It will pick a date as 14-9-2009 instead of 14-sep-2009. It will say:

      Failed to convert property value of type [java.lang.String] to required type [java.util.Date] for property birthDay; nested exception is java.lang.IllegalArgumentException: Could not parse date: Unparseable date: "14-9-2009"
      may not be null

      When changing my locale to english, it works (on IE8, but not in FF3.5).
      Also, non-required fields are rejected when not filled in.

        Issue Links

          Activity

          Hide
          Erik-Jan Blanksma added a comment -

          Hi Stefan,
          It's definitively a Dojo problem. If I go to http://dojocampus.org/explorer/#Dijit_Form%20Controls_Text%20Boxes_Date_Customized%201 with my locale set to dutch, It enters "2005 12 14" If I change it to english, it comes out as "14 December 2005". german comes out as "14. Dezember 2005". I'll see if I can file a problem report there.

          Problems seem to appear only if you are generating the application with a different locale to the one used by your browser.

          I'm certainly not changing locales between generating the application and viewing with my browser.

          The reason I'm suggesting to change the default pattern to some numeric date representation, is that the current default just doesn't work out-of-the-box. It just works if your browser locale is English, German or French and other big language (Just trying some out. Polish Greek or Danish don't work either). Sure there is a work around for it, by specifying the format yourself, but you have to figure that out first. Any user with an "uncommon" locale, that will try out roo and sets up petclinic, won't be able to enter an Owner. Some people will loose interest, because it just doesn't work (although it's a fault in Dojo).

          Furthermore, If YOU create a standard CRUD application using roo, you'll think it works great, until I try to access it, and won't be able to submit a form. It's really about giving people a false sense of flexibility. One my think "lets make the format "dd-MMMMM-yyyy", and you break your application. It's like promising the developer more than the framework of YOUR choice can offer.

          I don't think that hard-coding a date format is sensible at this time as there were users that expressed the need for localized date formats in the past and I believe that the default settings work well.

          I bet that ((SimpleDateFormat) DateFormat.getDateInstance(DateFormat.DEFAULT, Locale.getDefault())).toPattern(); always gives "d-MMM-yyyy" with any system default locale, as it's not the formatpattern, but the interpretation of it that's locale sensitive. So it's really hard coded atm as well. As I explained above, I don't think the default works well at all.

          Another thing I noticed is that it's now possible to switch locale from the default interface. Shouldn't the localization be applied to this datepicker as well? I noticed there is localization support for the DateTextBox http://dojotoolkit.org/book/dojo-porting-guide-0-4-x-0-9/widgets/datepicker . That way, you can at least make sure your application behaves independent of the locale setting of you user.

          Show
          Erik-Jan Blanksma added a comment - Hi Stefan, It's definitively a Dojo problem. If I go to http://dojocampus.org/explorer/#Dijit_Form%20Controls_Text%20Boxes_Date_Customized%201 with my locale set to dutch, It enters "2005 12 14" If I change it to english, it comes out as "14 December 2005". german comes out as "14. Dezember 2005". I'll see if I can file a problem report there. Problems seem to appear only if you are generating the application with a different locale to the one used by your browser. I'm certainly not changing locales between generating the application and viewing with my browser. The reason I'm suggesting to change the default pattern to some numeric date representation, is that the current default just doesn't work out-of-the-box. It just works if your browser locale is English, German or French and other big language (Just trying some out. Polish Greek or Danish don't work either). Sure there is a work around for it, by specifying the format yourself, but you have to figure that out first. Any user with an "uncommon" locale, that will try out roo and sets up petclinic, won't be able to enter an Owner. Some people will loose interest, because it just doesn't work (although it's a fault in Dojo). Furthermore, If YOU create a standard CRUD application using roo, you'll think it works great, until I try to access it, and won't be able to submit a form. It's really about giving people a false sense of flexibility. One my think "lets make the format "dd-MMMMM-yyyy", and you break your application. It's like promising the developer more than the framework of YOUR choice can offer. I don't think that hard-coding a date format is sensible at this time as there were users that expressed the need for localized date formats in the past and I believe that the default settings work well. I bet that ((SimpleDateFormat) DateFormat.getDateInstance(DateFormat.DEFAULT, Locale.getDefault())).toPattern(); always gives "d-MMM-yyyy" with any system default locale, as it's not the formatpattern, but the interpretation of it that's locale sensitive. So it's really hard coded atm as well. As I explained above, I don't think the default works well at all. Another thing I noticed is that it's now possible to switch locale from the default interface. Shouldn't the localization be applied to this datepicker as well? I noticed there is localization support for the DateTextBox http://dojotoolkit.org/book/dojo-porting-guide-0-4-x-0-9/widgets/datepicker . That way, you can at least make sure your application behaves independent of the locale setting of you user.
          Hide
          Erik-Jan Blanksma added a comment -

          I found a bug report for this at Dojo: http://bugs.dojotoolkit.org/ticket/8501
          Your supposed to localize it yourself, but I can't see how to do this in roo.

          Show
          Erik-Jan Blanksma added a comment - I found a bug report for this at Dojo: http://bugs.dojotoolkit.org/ticket/8501 Your supposed to localize it yourself, but I can't see how to do this in roo.
          Hide
          Ben Alex added a comment -

          Right now Roo supports specification of an explicit locale either via the @RooWebScaffold and also via the Roo shell (controller scaffold --dateFormat). If you disable JavaScript, that locale will always prevail and users seeing the JSP will be required to use that locale.

          Dojo, on the other hand, wants to localize the date format based on the user's browser. However, Roo in the JSP prescribes the specific date format to use and present to the browser, as per this example of Roo-generated code from clinic.roo:

          <script type="text/javascript">Spring.addDecoration(new Spring.ElementDecoration({elementId : '_birthDay', widgetType : 'dijit.form.DateTextBox', widgetAttrs : {constraints: {datePattern : 'dd/MM/yyyy', required : false}, datePattern : 'dd/MM/yyyy'}})); </script>
          

          Therefore Roo is doing everything it reasonably can to ensure all users of a Roo application will have a consistent date format.

          The present Roo model therefore allows flexible developer-nominated date formats on a per-controller basis, with convenient expression either via annotations, the shell or graceful fallback to the system default locale. I have read your earlier comment about new users potentially not specifying the correct date format and therefore seeing unexpected behavior, but I don't believe this is sufficient to ignore the system default locale if no locale is specified explicitly. We have done our own testing on the Sun JVM and it definitely is outputting a different locale, as shown above (we're in Australia here and that's the right format for here).

          I am inclined to close this bug report given I can't see an actual bug in Roo itself. Would you mind clarifying precisely what Roo is not outputting that you expect it should, or what Roo behavior you regard as problematic?

          Show
          Ben Alex added a comment - Right now Roo supports specification of an explicit locale either via the @RooWebScaffold and also via the Roo shell (controller scaffold --dateFormat). If you disable JavaScript, that locale will always prevail and users seeing the JSP will be required to use that locale. Dojo, on the other hand, wants to localize the date format based on the user's browser. However, Roo in the JSP prescribes the specific date format to use and present to the browser, as per this example of Roo-generated code from clinic.roo: <script type= "text/javascript" >Spring.addDecoration( new Spring.ElementDecoration({elementId : '_birthDay', widgetType : 'dijit.form.DateTextBox', widgetAttrs : {constraints: {datePattern : 'dd/MM/yyyy', required : false }, datePattern : 'dd/MM/yyyy'}})); </script> Therefore Roo is doing everything it reasonably can to ensure all users of a Roo application will have a consistent date format. The present Roo model therefore allows flexible developer-nominated date formats on a per-controller basis, with convenient expression either via annotations, the shell or graceful fallback to the system default locale. I have read your earlier comment about new users potentially not specifying the correct date format and therefore seeing unexpected behavior, but I don't believe this is sufficient to ignore the system default locale if no locale is specified explicitly. We have done our own testing on the Sun JVM and it definitely is outputting a different locale, as shown above (we're in Australia here and that's the right format for here). I am inclined to close this bug report given I can't see an actual bug in Roo itself. Would you mind clarifying precisely what Roo is not outputting that you expect it should, or what Roo behavior you regard as problematic?
          Hide
          Erik-Jan Blanksma added a comment -

          1. Roo uses the MEDIUM dateformat as default for input fields, which (depending on your JDK local) outputs "d-MMM-yyyy" or "MMM d,yyyy" or something like that. This causes a partial textual representation of the date.
          2. Dojo datepicker provides invalid input if your browser locale is not supported.
          3. I would like Roo to use ((SimpleDateFormat) DateFormat.getDateInstance(DateFormat.SHORT, Locale.getDefault())).toPattern(); to get the default pattern. This ensures a (still locale dependent) numerical representation of the date which always works.

          I think this would be an improvement, as the default would work for more people. But if you feel otherwise, feel free to close this issue, because, it's not really a bug in Roo itself.

          Anyway, thanks for your efforts.
          Regards,
          Erik-Jan

          Show
          Erik-Jan Blanksma added a comment - 1. Roo uses the MEDIUM dateformat as default for input fields, which (depending on your JDK local) outputs "d-MMM-yyyy" or "MMM d,yyyy" or something like that. This causes a partial textual representation of the date. 2. Dojo datepicker provides invalid input if your browser locale is not supported. 3. I would like Roo to use ((SimpleDateFormat) DateFormat.getDateInstance(DateFormat. SHORT , Locale.getDefault())).toPattern(); to get the default pattern. This ensures a (still locale dependent) numerical representation of the date which always works. I think this would be an improvement, as the default would work for more people. But if you feel otherwise, feel free to close this issue, because, it's not really a bug in Roo itself. Anyway, thanks for your efforts. Regards, Erik-Jan
          Hide
          Stefan Schmidt added a comment -

          Erik-Jan,

          Thanks again for pointing out the date format issues in different locales. It seems reasonable to change the format to DateFormat.SHORT if you say that resolves the locale issues with Dojo and a dutch locale. I have committed this change as of revision 303. This should be available in the upcoming RC2 release.

          I'll mark this ticket as resolved for now.

          -Stefan

          Show
          Stefan Schmidt added a comment - Erik-Jan, Thanks again for pointing out the date format issues in different locales. It seems reasonable to change the format to DateFormat.SHORT if you say that resolves the locale issues with Dojo and a dutch locale. I have committed this change as of revision 303. This should be available in the upcoming RC2 release. I'll mark this ticket as resolved for now. -Stefan

            People

            • Assignee:
              Stefan Schmidt
              Reporter:
              Erik-Jan Blanksma
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: