Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4A66062D.4070806@flexsecure.de>
Date: Tue, 21 Jul 2009 20:17:17 +0200
From: Lucas Satabin <satabin@flexsecure.de>
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: MyFaces Discussion <users@myfaces.apache.org>
Subject: Re: [Trinidad] tr:convertDateTime, pattern and client validation
References: <4A65B2C1.7020207@flexsecure.de> <4A66051A.9080707@oracle.com>
In-Reply-To: <4A66051A.9080707@oracle.com>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

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 <mailto:satabin@flexsecure.de>
>> Internet:    www.flexsecure.de <http://www.flexsecure.de>
>>
>> Gesch�ftsf�hrer:
>> Erwin Stallenberger, Markus Ruppert
>>
>> Amtsgericht Darmstadt HRB 8036
>> Umsatzsteuernummer: DE 214745269
>>   
>