[jira] Commented: (TRINIDAD-1538) Failing client side validation with some date patterns

["Cale Scholl (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/TRINIDAD-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12737766#action_12737766 ] 

Cale Scholl commented on TRINIDAD-1538:
---------------------------------------

Code change in DateFormat.js _subparse:

  var nextFormatType = (startIndex + charCount < inString.length) ?
    inString.charAt(startIndex + charCount) : null;

  // Consider the pattern "yyMMdd". Say that formatType is 'y' and
  // nextFormatType is 'M'. Normally we would allow for leniency such that
  // the user could input 2 or 4 digits for the year, but since this pattern
  // contains no date separators and both the year and month can consist of
  // digits, there's no easy way of telling whether the first 4 digits apply
  // to just the year, or to both the year and month. Therefore, if
  // nextFormatType is one of the reserved format types, then we go into
  // strict parsing mode for formatType, where charCount represents the
  // maximum number of user input characters that will be parsed when
  // matching the current formatType.
  var isStrict = (nextFormatType >= 'A') && (nextFormatType <= 'Z') ||
                 (nextFormatType >= 'a') && (nextFormatType <= 'z');

  ...

     case 'y': // year
     {
       var year = _accumulateNumber(parseContext, !isStrict ? 4 : charCount);
       ...

---

Although this 'isStrict' logic checking is probably only needed for the year,
since that is the only likely case where we would want to parse a number of
chars greater than charCount, I added this logic to other sections of
_subparse (such as for day and month) just to be on the safe side.

> Failing client side validation with some date patterns
> ------------------------------------------------------
>
>                 Key: TRINIDAD-1538
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1538
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Components
>    Affects Versions:  1.2.8-core
>            Reporter: Lucas Satabin
>         Attachments: 1.2.11.4-branch_dateFormat.patch, trunk_dateFormat.patch
>
>
> Some patterns can not be validated on the client side, using a convertDateTime component:
> Code to reproduce:
> <tr:inputDate value="#{bean.value}">
>     <f:convertDateTime pattern="yyMMdd" />
> </tr:inputDate>
> If you choose a date in the calendar, the formatting works fine in the text field. But when you submit, you receive an error message saying: valid example: 981124
> This value obviously does not work either.
> A workaround is to disable the client validation with <client-validation>DISABLED</client-validation> but we loose the client message when something is wrong (the valid example)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.