2

据我所知，用于转换属性/类名的标准 JavaBeans 约定用于 JSF EL，即方法对(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 使用示例都使用开头没有多个相邻大写字母的 bean 名称。在我设法找到的少数几个地方，建议不要以任何方式转换以多个大写字母开头的 bean 名称，即它应该URLManagerBean在前面的代码片段中。

不幸的是，我们有一个项目，其中很多 bean 都是这样命名的。在使用这些 bean 的任何地方，它们都遵循这个奇怪的，至少在某种程度上，约定：

class URLManagerBean -> uRLManagerBean

也就是说，只有首字母缩略词的首字母不大写。该项目似乎运行良好，因此该约定以某种方式起作用。但是 IntelliJ IDEA 不喜欢这样；它认为 JSF bean 真的应该像这样URLManagerBean命名，除非我通过注释显式重命名它。

class URLManagerBean我尝试更改from uRLManagerBeanto的用法URLManagerBean，但显然这不起作用-我尝试过的那些页面停止工作。

现在我认为这种奇怪约定背后的原因是我们通过SpringBeanFacesELResolver. 但是，此行为未在任何地方记录。

这种行为有什么解释吗？

4

1 回答 1

2

@ManagedBean您使用的是哪个注释？来自javax.faces.beanor的那个javax.annotation？

在第一种情况下，Spring 与它无关，因为它将是一个 JSF 托管 bean，并且将遵循 JSF 指定的约定。

name() 属性的值被视为 managed-bean-name。如果 name 属性的值未指定或为空字符串，则 managed-bean-name 派生自完全限定类名的非限定类名部分并将第一个字符转换为小写。例如，如果 ManagedBean 注解在具有完全限定类名称 com.example.Bean 的类上，并且注解上没有 name 属性，则将 managed-bean-name 视为 bean。此注释所附加到的类的完全限定类名被视为 managed-bean-class。来源：@ManagedBean javadocs

在第二种情况下，Spring 混合在一起，然后行为会根据您使用的 spring 版本和/或配置选项而有所不同。使用遵循指南AnnotationConfigApplicationContext的AnnotationBeanNameGeneratoris （并会导致 'URLManagerBean' 作为 bean 名称）。使用其他方法，您最终可能会DefaultBeanNameGenerator得到具有更简单算法的方法。

简单地说，它可能取决于您使用的 spring 版本和注释。

链接

于 2013-09-09T07:02:54.020 回答