Одно небольшое замечание к большому решению @BalusC. Если у нас есть
, который выполняет какой-либо метод в бэк-компоненте. Локаль, доступный из вызова FacesContext.getCurrentInstance().getViewRoot().getLocale()
внутри этого метода, был бы локалирован, который задается браузером пользователя или стандартным языковым стандартом приложения, а не той локалью, которая установлена на сеансовом компоненте по выбору пользователя (конечно, они могут совпадать, если язык браузера равен этой локали, пользователь выбран).
Я могу выдержать исправление, потому что, возможно, я сделал что-то неправильно при реализации решения, предоставленного @BalusC.
EDIT. После игры с жизненным циклом JSF это поведение с локалью не связано с
, поскольку аналогичное поведение наблюдается и с @PostContruct
.
в запросе (после выбранного пользователем локали) выполняется в фазе ответа рендера.
и @PostContruct
методы выполняются при вызове фазы приложения. Вот почему логика, которая выполняется в этом методе, не имеет доступа к выбранному пользователем языку.
Решение, которое мы используем, когда мы нуждаемся в правильной локали, заключается в том, чтобы вводить (CDI) localeBean
в другой бэк-компонент, содержащий
и @PostContruct
, а затем установить locale с UIViewRoot#setLocale()
из localeBean
в начале этих методов.
Ответ является желанием людей придерживаться Приложение C спецификации XHTML1.0. Который только необходимо сделать, если Вы обслуживание XHTML как текст/HTML . Который делает большинство людей, потому что реальный тип MIME XHTML (application/html+xml) не работает в Internet Explorer.
Никакой текущий браузер не заботится о пространстве. Браузеры очень терпимы к этим вещам.
пространство раньше требовалось, чтобы гарантировать, что синтаксические анализаторы HTML рассматривали запаздывающую наклонную черту как нераспознанный атрибут.
те проблемы все еще релевантны, или мы все еще добавляем дополнительные пространства ради, скажем, совместимости IE3?
Вы были близки - это для Netscape 4.
интересно видеть другие модернизации, но это - все, для чего это было предназначено.
Нет, пространство не требуется, но необходимо для некоторых более старых браузеров представить те теги правильно. Надлежащий способ сделать это без дополнительного пространства, как это - что-то XHTML, наследованный от XML.
В XHTML теги br должны быть закрыты, , но пространство не необходимо . Это - стилистическая вещь. В HTML не могут быть закрыты теги br, таким образом, оба неправы.
Я думаю, что пробел является способом укрепить идею, что этот тег пуст, и это закрывает себя.
Сегодня я больше не использую пробел, потому что у меня никогда не было проблемы без пробела.
Пространство просто делает теги более читаемыми. Я - крупный сторонник форматирования для большего количества читаемого кода. Небольшие подобные вещи имеют большое значение. Без пространства закрывающий тэг гармонирует с открывающим тэгом. Требуется только момент дольше для меня для обработки его, поскольку я быстро читаю код.