Issue Details (XML | Word | Printable)

Key: JAVASERVERFACES_SPEC_PUBLIC-201
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: tony_robertson
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
javaserverfaces-spec-public

Locale handling in f:convertDateTime and f:convertNumber

Created: 06/Aug/06 04:19 PM   Updated: 24/Jan/14 09:53 PM
Component/s: Validation/Conversion
Affects Version/s: 2.2 Sprint 8
Fix Version/s: 2.3

Time Tracking:
Not Specified

Environment:

Operating System: All
Platform: All


Issuezilla Id: 201
Status Whiteboard:

EGEasy5 cat2 frame size_small importance_medium

Tags:
Participants: Ed Burns, rogerk and tony_robertson


 Description  « Hide

The handling of the "locale" attribute in the JSF core taglib tags
<f:convertDateTime> and <f:convertNumber> is inconsistent with each other and
with the handling of the "locale" attribute in the <f:view> view-root tag.

For <f:convertDateTime>, the description mandates that the implementation must
pass any string value as the first arg to the two-arg Locale constructor, and
pass the empty string as the second arg.

For <f:convertNumber>, the tld docs imply that string values are not supported
at all, but the sun javaserverfaces api implementation does allow literal
strings that are treated the same way as for <f:convertDateTime>.

In both cases, it would be more useful and consistent if String values were
treated as references to locale "names" using the same syntax as for the
<f:view> locale attribute (ie, allow language-country-variant type strings).

Placing support for a standard "locale" attribute in the <f:converter> tag may
be a good way to provide consistent behaviour for both <f:convertDateTime>,
<f:convertNumber>, and any user supplied custom converters.