Насколько мне известно, в JSF EL используется стандартное соглашение JavaBeans для преобразования имен свойств / классов, т.е. пары методов (get|is)Property + setProperty преобразуются только в property:
public class SomeComponent {
public String getAttribute() { ... }
public void setAttribute(String attribute) { ... }
}
<h:outputText value="#{comp.attribute}" />
То же самое и с именами bean-компонентов (если только эти имена не указаны напрямую в аннотации @ManagedBean):
@ManagedBean
public class UsefulBean {
...
}
<h:outputText value="#{usefulBean.doSomething()}" />
Такое поведение в основном задокументировано. Однако мне не удалось найти ничего о соглашениях о преобразовании, когда имена bean-компонентов или свойств начинаются с акронима, например
@ManagedBean
public class URLManagerBean {
}
<h:outputText value="#{...ManagerBean.doSomething()}" />
Что должно быть вместо многоточия в предыдущем фрагменте?
Удивительно, но в Интернете практически нет информации об этом. Почти все примеры использования управляемых компонентов JSF используют имена компонентов без нескольких соседних заглавных букв в начале. В нескольких местах, которые мне удалось найти, предлагается, чтобы имена bean-компонентов, начинающиеся с нескольких заглавных букв, никак не преобразовывались, т.е. в предыдущем фрагменте кода это было бы URLManagerBean.
К сожалению, у нас есть проект, в котором многие бины названы именно так. И везде, где используются эти бобы, они следуют этому странному, в меньшей степени, соглашению:
class URLManagerBean -> uRLManagerBean
То есть декапитализирована только первая буква аббревиатуры. Похоже, что проект работает хорошо, так что это соглашение как-то работает. Но IntelliJ IDEA это не нравится; он считает, что bean-компоненты JSF действительно должны называться URLManagerBean, если я не переименую их явно через аннотацию.
Я попытался изменить использование class URLManagerBean с uRLManagerBean на URLManagerBean, но, видимо, это не сработало - те страницы, на которых я это пробовал, перестали работать.
Теперь я думаю, что причина такого странного соглашения в том, что мы используем интеграцию Spring через SpringBeanFacesELResolver. Однако такое поведение нигде не задокументировано.
Есть какое-нибудь объяснение такому поведению?