You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Yee-wah Lee <ye...@oracle.com> on 2009/07/21 20:12:42 UTC
Re: [Trinidad] tr:convertDateTime, pattern and client validation
Hi Lucas,
I was able to reproduce this. The problem is in the client datetime
converter, which assumes that years occupy 4 digits.
function _subparse (..)
case 'y': // year
var year = _accumulateNumber(parseContext, 4);
So, it parses a string like "981122" and gets year=9811, then runs out
of digits for the month and day. This hasn't been a more common problem
because there is usually a separator ('/' in en_us), so when the parse
encounters the separator char, it doesn't try to consume more
characters. In the en_us case, after it parses out year=98, it will fix
it to 1998 in _fix2DYear.
I'm not familiar with the history of "shortish" in the converter, it may
be why the client code assumes 4 characters for years. Tag doc states:
The default dateStyle is |shortish|. Shortish is identical to
|short| but forces the year to be a full four digits. |dateStyle|
defaults to |shortish| if it was not set.
If anyone knows if there is a limitation on date time converter
regarding 2 digit years, please chime in. Otherwise, this sounds like a
bug (workaround: use 4 digit years or separator char).
Yee-Wah
Lucas Satabin wrote:
> Hello everybody,
>
> I am trying to convert an input into a date using Trinidad.
> <tr:inputDate rendered="#{col.date}"
> value="#{co.value}"
> disabled="#{!col.edit}"
> required="false">
> <tr:convertDateTime pattern="#{col.pattern}" />
> </tr:inputDate>
>
> It works fine for almost each pattern. I am however facing some
> problems when the pattern becomes "yyMMdd"
> In this case, as long as the client validation is allowed. I do not
> have this problem anymore if I disable the client validation with
>
> <client-validation>DISABLED</client-validation>
>
> With the client validation enabled, the value is never committed as
> far as the validation fails. It prints : valid example: 981122
> Obviously this example value does not work either. Is this problem
> known? I searched for this but did not find anything.
>
> Thanks in advance
> Lucas
>
> --
> Ingénieur diplômé ENSEEIHT (Informatique) Lucas Satabin
> Entwickler
>
> FlexSecure GmbH
> Industriestr. 12
> D-64297 Darmstadt
> Tel.: +49 (0) 6151 501 23-15
> Fax.: +49 (0) 6151 501 23-19
> E-mail: satabin@flexsecure.de <ma...@flexsecure.de>
> Internet: www.flexsecure.de <http://www.flexsecure.de>
>
> Geschäftsführer:
> Erwin Stallenberger, Markus Ruppert
>
> Amtsgericht Darmstadt HRB 8036
> Umsatzsteuernummer: DE 214745269
>
Re: [Trinidad] tr:convertDateTime, pattern and client validation
Posted by Yee-wah Lee <ye...@oracle.com>.
Hi Lucas,
Yes, I suggest you file a JIRA with your use case.
Yee-Wah
Lucas Satabin wrote:
> Hi Zee-wah
>
> Thanks for the answer. It is also what I thought. I can not however not
> change the pattern because it is a part of a file name I receive that I
> must test. Should I open a ticket for this bug? As a workaround I
> disabled the client validation and I do not have any problem anymore,
> but I do not have the client message anymore :(
>
> Lucas
>
> Zee-wah Lee a écrit :
>
>> Hi Lucas,
>>
>> I was able to reproduce this. The problem is in the client datetime
>> converter, which assumes that years occupy 4 digits.
>> function _subparse (..)
>> case 'y': // year
>> var year = _accumulateNumber(parseContext, 4);
>>
>> So, it parses a string like "981122" and gets year=9811, then runs
>> out of digits for the month and day. This hasn't been a more common
>> problem because there is usually a separator ('/' in en_us), so when
>> the parse encounters the separator char, it doesn't try to consume
>> more characters. In the en_us case, after it parses out year=98, it
>> will fix it to 1998 in _fix2DYear.
>>
>> I'm not familiar with the history of "shortish" in the converter, it
>> may be why the client code assumes 4 characters for years. Tag doc
>> states:
>>
>> The default dateStyle is |shortish|. Shortish is identical to
>> |short| but forces the year to be a full four digits. |dateStyle|
>> defaults to |shortish| if it was not set.
>>
>> If anyone knows if there is a limitation on date time converter
>> regarding 2 digit years, please chime in. Otherwise, this sounds like
>> a bug (workaround: use 4 digit years or separator char).
>>
>> Yee-Wah
>>
>>
>>
>>
>> Lucas Satabin wrote:
>>
>>> Hello everybody,
>>>
>>> I am trying to convert an input into a date using Trinidad.
>>> <tr:inputDate rendered="#{col.date}"
>>> value="#{co.value}"
>>> disabled="#{!col.edit}"
>>> required="false">
>>> <tr:convertDateTime pattern="#{col.pattern}" />
>>> </tr:inputDate>
>>>
>>> It works fine for almost each pattern. I am however facing some
>>> problems when the pattern becomes "yyMMdd"
>>> In this case, as long as the client validation is allowed. I do not
>>> have this problem anymore if I disable the client validation with
>>>
>>> <client-validation>DISABLED</client-validation>
>>>
>>> With the client validation enabled, the value is never committed as
>>> far as the validation fails. It prints : valid example: 981122
>>> Obviously this example value does not work either. Is this problem
>>> known? I searched for this but did not find anything.
>>>
>>> Thanks in advance
>>> Lucas
>>>
>>> --
>>> Ingénieur diplômé ENSEEIHT (Informatique) Lucas Satabin
>>> Entwickler
>>>
>>> FlexSecure GmbH
>>> Industriestr. 12
>>> D-64297 Darmstadt
>>> Tel.: +49 (0) 6151 501 23-15
>>> Fax.: +49 (0) 6151 501 23-19
>>> E-mail: satabin@flexsecure.de <ma...@flexsecure.de>
>>> Internet: www.flexsecure.de <http://www.flexsecure.de>
>>>
>>> Geschäftsführer:
>>> Erwin Stallenberger, Markus Ruppert
>>>
>>> Amtsgericht Darmstadt HRB 8036
>>> Umsatzsteuernummer: DE 214745269
>>>
>>>
>
>
Re: [Trinidad] tr:convertDateTime, pattern and client validation
Posted by Lucas Satabin <sa...@flexsecure.de>.
Hi Zee-wah
Thanks for the answer. It is also what I thought. I can not however not
change the pattern because it is a part of a file name I receive that I
must test. Should I open a ticket for this bug? As a workaround I
disabled the client validation and I do not have any problem anymore,
but I do not have the client message anymore :(
Lucas
Zee-wah Lee a écrit :
> Hi Lucas,
>
> I was able to reproduce this. The problem is in the client datetime
> converter, which assumes that years occupy 4 digits.
> function _subparse (..)
> case 'y': // year
> var year = _accumulateNumber(parseContext, 4);
>
> So, it parses a string like "981122" and gets year=9811, then runs
> out of digits for the month and day. This hasn't been a more common
> problem because there is usually a separator ('/' in en_us), so when
> the parse encounters the separator char, it doesn't try to consume
> more characters. In the en_us case, after it parses out year=98, it
> will fix it to 1998 in _fix2DYear.
>
> I'm not familiar with the history of "shortish" in the converter, it
> may be why the client code assumes 4 characters for years. Tag doc
> states:
>
> The default dateStyle is |shortish|. Shortish is identical to
> |short| but forces the year to be a full four digits. |dateStyle|
> defaults to |shortish| if it was not set.
>
> If anyone knows if there is a limitation on date time converter
> regarding 2 digit years, please chime in. Otherwise, this sounds like
> a bug (workaround: use 4 digit years or separator char).
>
> Yee-Wah
>
>
>
>
> Lucas Satabin wrote:
>> Hello everybody,
>>
>> I am trying to convert an input into a date using Trinidad.
>> <tr:inputDate rendered="#{col.date}"
>> value="#{co.value}"
>> disabled="#{!col.edit}"
>> required="false">
>> <tr:convertDateTime pattern="#{col.pattern}" />
>> </tr:inputDate>
>>
>> It works fine for almost each pattern. I am however facing some
>> problems when the pattern becomes "yyMMdd"
>> In this case, as long as the client validation is allowed. I do not
>> have this problem anymore if I disable the client validation with
>>
>> <client-validation>DISABLED</client-validation>
>>
>> With the client validation enabled, the value is never committed as
>> far as the validation fails. It prints : valid example: 981122
>> Obviously this example value does not work either. Is this problem
>> known? I searched for this but did not find anything.
>>
>> Thanks in advance
>> Lucas
>>
>> --
>> Ingénieur diplômé ENSEEIHT (Informatique) Lucas Satabin
>> Entwickler
>>
>> FlexSecure GmbH
>> Industriestr. 12
>> D-64297 Darmstadt
>> Tel.: +49 (0) 6151 501 23-15
>> Fax.: +49 (0) 6151 501 23-19
>> E-mail: satabin@flexsecure.de <ma...@flexsecure.de>
>> Internet: www.flexsecure.de <http://www.flexsecure.de>
>>
>> Geschäftsführer:
>> Erwin Stallenberger, Markus Ruppert
>>
>> Amtsgericht Darmstadt HRB 8036
>> Umsatzsteuernummer: DE 214745269
>>
>