Announcement Announcement Module
Collapse
No announcement yet.
Date Format problem Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Date Format problem

    Hi i'm here again..
    I don't understand the whole thing... why support an annotation @DateTimeFormat
    if the only automatic managing is the default one, with the "S-" value?
    Changing it does not change the rest of the app so that the dojo widgets ( on the update.jspx ) continues to work.
    It's confusing to have something there that seems to do some automatic work, but it does only for the default value. You have to implemet custom converters for all the rest, like you do for all your custom classes.
    I lost a lot of time only understanding this: it was not my combination of patterns for entity and controller addDateTimeFormatPatterns method that does not work. The only values avalable that works for these two are "S-" pattern, the default ones. For all the remaining formats you have to manage all the date format issue in a different way, or you get an error on the date widget.

    As is the S- does not work for date with historical years like 01/01/1911 that is traslated to 01/01/11 and then to 01/01/2011.
    Have we here again Y2K bug,?

  • #2
    The main reason why we can only supply a limited range of the many configuration options that @DateTimeFormat offers is that the mapping with Dojo supported Date formatting is limited. There is however always room for improvement. Feel free to contribute a patch if you feel strongly about it . I think writing a custom converter is not that hard given Roo already gives you examples and takes care of all configuration. All you need to do is push in a method and change one line of code.

    The 1911 > 2011 issue is interesting and we should take a closer look. Can you please open a Jira ticket?

    Comment


    • #3
      You are right, it's not complex to write a converter, it's only not clear that you have to do. When you are new to a framework you don't know the every aspect of it you try to solve these kind of problems with the options that seems to be there. To my interpretation Roo is something that point to improve your productivity and when you see the annotation @DateTimeFormat with option for other style, iso or pattern you think you can use it, or that find in documentation a big warning. I've received an hint like that only when i've changed the DateTimeFormat pattern on the entity, but none for addDateTimeFormatPatterns method (and i don't know if is technically possible to receive one). Changing addDateTimeFormatPatterns it's the logical approach when you are interested to change only the visualization of the data.. but it's not supported any other kind of format!
      These are the situations you would avoid when you use something like Roo. It's perfectly fine that Roo can't do everything, but I hope to receive clear hint like, "do it yourself, and I suggest use this way/pattern/best practice" so you don't have to lose time trying to use a feauture that does not exist.
      My only question to choose to use Roo or not is.. "Can it improve my developing time or if I sway a little from the default behaviour there is no real improvement , and only an increased complexity?"

      I will fill a jira ticket for the other problem explaining better but it's simply that the pattern for almost all Locales "S-" is something like "dd/MM/yy" or "MM/dd/yy", so even if the widget displays with "yyyy" format with some assumption, how could the application preserve the millennium and century? Just try to input from a widget a date like 01/01/1911 on look at what is written on the DB.

      Comment


      • #4
        I've managed to solve the problem without using a filter but it's a bit of manual work and I think it could be managed by ROO,
        the main problem is that when you change the "S-" pattern the call to addDateTimeFormatPatterns(uiModel) is removed by Roo
        from every method of XXXController_Roo_Controller.aj.

        Take a field Date from an entity manage by Roo ( XXX_Roo_DbManaged.aj ):
        Code:
            @Column(name = "DATACAMBIOPSW")
            @Temporal(TemporalType.TIMESTAMP)
            @DateTimeFormat(style = "S-")
            private Date mydate;
        and put in in you main entity class ( XXX.java ) changing the pattern:
        Code:
            @Column(name = "DATACAMBIOPSW")
            @Temporal(TemporalType.TIMESTAMP)
            @DateTimeFormat(iso = ISO.DATE) //yyyy-MM-dd
            private Date mydate;
        or a personal pattern:
        Code:
            @Column(name = "DATACAMBIOPSW")
            @Temporal(TemporalType.TIMESTAMP)
            @DateTimeFormat(pattern = "dd/MM/YYYY") 
            private Date mydate;
        then in XXXController.java put a method to valorize the seme patten for the views(here only the first example with ISO date):
        Code:
            void addDateTimeFormatPatterns(Model uiModel) {
                uiModel.addAttribute("xXX_mydate_date_format", "yyyy-MM-dd");
            }
        and then take all the methods from XXXController_Roo_Controller.aj to re-add the call to addDateTimeFormatPatterns removed by ROO.
        here an example for only for the update method:
        Code:
            @RequestMapping(value = "/{id}", params = "form", method = RequestMethod.GET)
            public String updateForm(@PathVariable("id") BigDecimal id, Model uiModel) {
                uiModel.addAttribute("xXX", XXX.findXXX(id));
                addDateTimeFormatPatterns(uiModel);
                return "xxx/update";
            }
        now you have a working widget on the view page with a personal pattern, but you have to manage all by hand. I think that all this could be done by ROO.

        Another thing is that with some extra efford roo could have a date field locale aware, dojo permit this:
        http://download.dojotoolkit.org/rele...teTextBox.html
        see first example, the input is yyyy-MM-dd but on the widget you get the default format for your locale (mine is dd/MM/yyyy)
        In roo an error is raised if the field passing have a format different from the pattern displayed.

        I don't know why, but changing datetime.tagx like this does not work as on the dojo example. ( and passing date with format yyyy-MM-dd as showed above)
        Code:
        Spring.addDecoration(new Spring.ElementDecoration({elementId : '_${sec_field}_id', widgetType : 'dijit.form.DateTextBox', widgetAttrs : {promptMessage: '${sec_field_validation}', invalidMessage: '${sec_field_invalid}', required: ${required} }}));
        Last edited by Macs; Jun 28th, 2011, 09:21 AM.

        Comment


        • #5
          jira

          here the jira for the Y2K bug:

          https://jira.springsource.org/browse/ROO-2534

          Comment

          Working...
          X