Details
Description
This is probably the simplest solution for ICE-1505, and may be required for ICE-2419.
When sending the page to the browser, it would be nice if we could take the locale id in UIViewRoot.getLocale(), and make that available to the bridge Javascript, so that it could make that locale id be the first entry in the Accept-Language request header. This is necessary because when components render their output in a certain locale in one lifecycle, the validation phase in the subsequent lifecycle must use the same locale, so that dates, numbers, currencies, etc. will be parsable and validatable. It also would keep the locale sticky, for when developers programmatically set the locale, and expect it to remain until they set it to a different value.
As it stands, without this change, some JSF RI code in com.sun.faces.lifecycle.RestoreViewPhase.execute(FacesContext) can stomp over the correct locale, with whatever happens to be the first one listed in the Accept-Language request header.
When sending the page to the browser, it would be nice if we could take the locale id in UIViewRoot.getLocale(), and make that available to the bridge Javascript, so that it could make that locale id be the first entry in the Accept-Language request header. This is necessary because when components render their output in a certain locale in one lifecycle, the validation phase in the subsequent lifecycle must use the same locale, so that dates, numbers, currencies, etc. will be parsable and validatable. It also would keep the locale sticky, for when developers programmatically set the locale, and expect it to remain until they set it to a different value.
As it stands, without this change, some JSF RI code in com.sun.faces.lifecycle.RestoreViewPhase.execute(FacesContext) can stomp over the correct locale, with whatever happens to be the first one listed in the Accept-Language request header.
Issue Links
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion