Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-7066

temporal expression screen missing date dialogbox

    Details

      Description

      go to https://localhost:8443/webtools/control/editTemporalExpression
      go to frequency expression section
      notice date dialog button is missing

      1. example_solution
        2 kB
        Montalbano Florian

        Activity

        Hide
        Florian M Montalbano Florian added a comment - - edited

        Hi Wai,

        the problem seems to be related to a conflict of id when the page is build from the template.

        Here are the input code from a working form in the same page (Date Range) :

        <input name="date1_i18n" title="Format: yyyy-MM-dd HH:mm:ss.SSS" size="25" maxlength="30" id="date11_i18n" type="text">

        The date dialog is present.

        The input code for the not working one (Frequency) :

        <input name="date1_i18n" title="Format: yyyy-MM-dd HH:mm:ss.SSS" size="25" maxlength="30" id="date11_i18n" type="text">

        It's the exact same id (and same code).

        From W3C :

        The id attribute specifies a unique id for an HTML element (the value must be unique within the HTML document).

        And here it's confusing the javascript or something resulting in this following difference in the line just after each input :
        Working one =>

        <input id="date11" class="hasDatepicker" name="date1" title="Format: yyyy-MM-dd HH:mm:ss.SSS" size="25" maxlength="30" type="hidden">

        Broken one =>

        <input date11 name="date1" title="Format: yyyy-MM-dd HH:mm:ss.SSS" size="25" maxlength="30" type="hidden">

        The class "hasDatepicker" is not added and thus the date dialog button is not created.

        Root of the problem :
        In the template tempExprMacros.ftl, the input type is "DateField". The id of a DateField is created as follow :

        ${fieldName} + "1".
        

        Both form are using "date1" as fieldName resulting in this id conflict.

        I will provide a example of solution (easy workaround not a final solution) to illustrate the working behaviour when the id conflict is avoided.

        Have a nice day.

        Florian

        Show
        Florian M Montalbano Florian added a comment - - edited Hi Wai, the problem seems to be related to a conflict of id when the page is build from the template. Here are the input code from a working form in the same page (Date Range) : <input name= "date1_i18n" title= "Format: yyyy-MM-dd HH:mm:ss.SSS" size= "25" maxlength= "30" id= "date11_i18n" type= "text" > The date dialog is present. The input code for the not working one (Frequency) : <input name= "date1_i18n" title= "Format: yyyy-MM-dd HH:mm:ss.SSS" size= "25" maxlength= "30" id= "date11_i18n" type= "text" > It's the exact same id (and same code). From W3C : The id attribute specifies a unique id for an HTML element (the value must be unique within the HTML document). And here it's confusing the javascript or something resulting in this following difference in the line just after each input : Working one => <input id= "date11" class= "hasDatepicker" name= "date1" title= "Format: yyyy-MM-dd HH:mm:ss.SSS" size= "25" maxlength= "30" type= "hidden" > Broken one => <input date11 name= "date1" title= "Format: yyyy-MM-dd HH:mm:ss.SSS" size= "25" maxlength= "30" type= "hidden" > The class "hasDatepicker" is not added and thus the date dialog button is not created. Root of the problem : In the template tempExprMacros.ftl, the input type is "DateField". The id of a DateField is created as follow : ${fieldName} + "1" . Both form are using "date1" as fieldName resulting in this id conflict. I will provide a example of solution (easy workaround not a final solution) to illustrate the working behaviour when the id conflict is avoided. Have a nice day. Florian
        Hide
        jacques.le.roux Jacques Le Roux added a comment -

        Thanks Wai for report,

        Thanks to Florian analysis I committed a fix in
        trunk r1791791
        R16.11 r1791792

        I consider the bug minor and will not backport further

        Show
        jacques.le.roux Jacques Le Roux added a comment - Thanks Wai for report, Thanks to Florian analysis I committed a fix in trunk r1791791 R16.11 r1791792 I consider the bug minor and will not backport further

          People

          • Assignee:
            jacques.le.roux Jacques Le Roux
            Reporter:
            wt Wai
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development