Roger,
We have several combos whose values are read from outside systems, and sometimes those values have strings with Unicode characters. Normally the (code, description) pair only contains Unicode characters on the description string, but in rare occasions it can contain Unicode characters (ç, for example) on the code string (bad practice, I know...).
I've worked around this issue by manually escaping and unescaping the itemValue on the problematic combos, and marking the code for future review.
I think this bug is serious because anyone that has combos wired to tables that are feeded externally may one day wake up with a broken application, just because some outside system updated some decode table.
However, this can clearly wait until 2.0!
The reason for my original email was that this issue hasn't targeted to 2.0, and I was afraid it would fall into oblivion.
If you don't mind, I wish to give my feedback to the proposed fix, and since I can't comment on the issue on the site, I'll grab this opportunity and do it here:
I don't quite agree with the proposed fix that suggests an optional escape attribute. I think the validation of the itemValue should be relaxed to allow more complex values, like strings with Unicode characters.
A quick look at the HTML4 Spec I have found no hint that the existing restrictions on Unicode characters should ever exist for itemValue since the "value" attribute on the <OPTION> element is defined as CDATA in the HTML4 Spec.
Thanks,
José Freire
Consulting - Financial Services Industry
Deloitte & Touche, Quality Firm, S.A.
Main: +(351) 21 042 25 00
Fax: +(351) 21 042 29 50
jfreire_at_deloitte.pt
www.deloitte.com/pt
Deloitte
Edifício Atrium Saldanha
Praça Duque de Saldanha, 1 - 7º
1050-094 Lisboa
Portugal
-----Original Message-----
From: Roger.Kitain_at_Sun.COM [mailto:Roger.Kitain_at_Sun.COM]
Sent: quarta-feira, 19 de Março de 2008 18:53
To: dev_at_javaserverfaces.dev.java.net
Subject: Re: JSF 1.2 open spec defects
Hello Jose,
Is this defect causing serious problems now? What is *your* specific
use case?
This issue has been on the table
since Jan 2007, and we would really appreciate it if it could wait until
2.0 - we are
resource challenged here, and things like this will deter us from 2.0.
If this is
a serious problem in your apps, you could have your own Responsewriter in
the interim. Please let us know if that will work for you (either
waiting for 2.0 or
custom Responsewriter) - we want to make sure we address your needs.
Thanks, Roger.
Freire, Jose Luis (PT - Lisbon) wrote:
> Hi Roger,
>
> What about the double escaping issue?
>
> Spec issue: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=237
> Impl issue: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=464
>
> It's a real problem for foreign language applications, and it's still targeted to 1.2.
>
> Thanks,
>
> José Freire
> Consulting - Financial Services Industry
> Deloitte & Touche, Quality Firm, S.A.
>
> Main: +(351) 21 042 25 00
> Fax: +(351) 21 042 29 50
> jfreire_at_deloitte.pt
> www.deloitte.com/pt
>
> Deloitte
> Edifício Atrium Saldanha
> Praça Duque de Saldanha, 1 - 7º
> 1050-094 Lisboa
> Portugal
> -----Original Message-----
> From: Roger.Kitain_at_Sun.COM [mailto:Roger.Kitain_at_Sun.COM]
> Sent: terça-feira, 18 de Março de 2008 20:28
> To: dev_at_javaserverfaces.dev.java.net
> Subject: Re: JSF 1.2 open spec defects
>
> w/r/t the locale defect - we are looking at doing an 1.2 MR for that.
>
> Thanks, Roger.
>
> Freire, Jose Luis (PT - Lisbon) wrote:
>
>> Hi everyone!
>>
>>
>>
>> What will happen to all the 1.2 spec defects? Will they move to 2.0?
>>
>>
>>
>> *José Freire
>> *Consulting - Financial Services Industry
>> Deloitte & Touche, Quality Firm, S.A.
>>
>> Main: +(351) 21 042 25 00
>> Fax: +(351) 21 042 29 50
>> jfreire_at_deloitte.pt
>> www.deloitte.com/pt
>>
>> Deloitte
>> Edifício Atrium Saldanha
>> Praça Duque de Saldanha, 1 - 7º
>> 1050-094 Lisboa
>> Portugal
>>
>>
>> *Disclaimer:*
>> Deloitte refers to one or more of Deloitte Touche Tohmatsu, a Swiss
>> Verein, its member firms, and their respective subsidiaries and
>> affiliates. As a Swiss Verein (association), neither Deloitte Touche
>> Tohmatsu nor any of its member firms has any liability for each
>> other's acts or omissions. Each of the member firms is a separate and
>> independent legal entity operating under the names "Deloitte,"
>> "Deloitte & Touche," "Deloitte Touche Tohmatsu," or other related
>> names. Services are provided by the member firms or their
>> subsidiaries or affiliates and not by the Deloitte Touche Tohmatsu Verein.
>> Privileged/Confidential Information may be contained in this message.
>> If you are not the addressee indicated in this message (or responsible
>> for delivery of the message to such person), you may not copy or
>> deliver this message to anyone. In such case, you should destroy this
>> message and kindly notify the sender by reply email. Please advise
>> immediately if you or your employer do not consent to Internet email
>> for messages of this kind. Opinions, conclusions and other information
>> in this message that do not relate to the official business of my firm
>> shall be understood as neither given nor endorsed by it.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net