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.

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.

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?

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

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