Пространство перед заключительной наклонной чертой?

Одно небольшое замечание к большому решению @BalusC. Если у нас есть , который выполняет какой-либо метод в бэк-компоненте. Локаль, доступный из вызова FacesContext.getCurrentInstance().getViewRoot().getLocale() внутри этого метода, был бы локалирован, который задается браузером пользователя или стандартным языковым стандартом приложения, а не той локалью, которая установлена ​​на сеансовом компоненте по выбору пользователя (конечно, они могут совпадать, если язык браузера равен этой локали, пользователь выбран).

Я могу выдержать исправление, потому что, возможно, я сделал что-то неправильно при реализации решения, предоставленного @BalusC.

EDIT. После игры с жизненным циклом JSF это поведение с локалью не связано с , поскольку аналогичное поведение наблюдается и с @PostContruct. в запросе (после выбранного пользователем локали) выполняется в фазе ответа рендера. и @PostContruct методы выполняются при вызове фазы приложения. Вот почему логика, которая выполняется в этом методе, не имеет доступа к выбранному пользователем языку.

Решение, которое мы используем, когда мы нуждаемся в правильной локали, заключается в том, чтобы вводить (CDI) localeBean в другой бэк-компонент, содержащий и @PostContruct, а затем установить locale с UIViewRoot#setLocale() из localeBean в начале этих методов.

87
задан Greg Mattes 22 January 2009 в 20:57
поделиться

6 ответов

Ответ является желанием людей придерживаться Приложение C спецификации XHTML1.0. Который только необходимо сделать, если Вы обслуживание XHTML как текст/HTML . Который делает большинство людей, потому что реальный тип MIME XHTML (application/html+xml) не работает в Internet Explorer.

Никакой текущий браузер не заботится о пространстве. Браузеры очень терпимы к этим вещам.

пространство раньше требовалось, чтобы гарантировать, что синтаксические анализаторы HTML рассматривали запаздывающую наклонную черту как нераспознанный атрибут.

60
ответ дан Lee Kowalkowski 5 November 2019 в 15:30
поделиться

те проблемы все еще релевантны, или мы все еще добавляем дополнительные пространства ради, скажем, совместимости IE3?

Вы были близки - это для Netscape 4.

интересно видеть другие модернизации, но это - все, для чего это было предназначено.

24
ответ дан bobince 5 November 2019 в 15:30
поделиться

Нет, пространство не требуется, но необходимо для некоторых более старых браузеров представить те теги правильно. Надлежащий способ сделать это без дополнительного пространства, как это - что-то XHTML, наследованный от XML.

4
ответ дан Andrew Hare 5 November 2019 в 15:30
поделиться

В XHTML теги br должны быть закрыты, , но пространство не необходимо . Это - стилистическая вещь. В HTML не могут быть закрыты теги br, таким образом, оба неправы.

3
ответ дан Pesto 5 November 2019 в 15:30
поделиться

Я думаю, что пробел является способом укрепить идею, что этот тег пуст, и это закрывает себя.

Сегодня я больше не использую пробел, потому что у меня никогда не было проблемы без пробела.

-1
ответ дан nicruo 5 November 2019 в 15:30
поделиться

Пространство просто делает теги более читаемыми. Я - крупный сторонник форматирования для большего количества читаемого кода. Небольшие подобные вещи имеют большое значение. Без пространства закрывающий тэг гармонирует с открывающим тэгом. Требуется только момент дольше для меня для обработки его, поскольку я быстро читаю код.

1
ответ дан Jim Petkus 5 November 2019 в 15:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: