我是否误解了 JavaBean 方法命名约定,或者这是一种异常情况?
我的代码中发生了神秘的事情。这是 bean 的片段:
public List<HelpContentsFrag> getCFrags()
{
return cFrags;
}
public void setCFrags(List<HelpContentsFrag> frags)
{
cFrags = frags;
}
这是我的视图代码(标记文件)的片段
cFrags:[${topic.cFrags}]
,其中 topic 是 bean 类型的对象。
这是错误:
javax.el.PropertyNotFoundException: Property 'cFrags' not found on type com.company.beans.BeanClass
还需要考虑一件事。 eclipse 生成的 setter 中有一个细微的差别。显然,它也不喜欢cFrags这个名字。字段名称是 cFrags,对于所有其他设置器,我获取与字段同名的参数,并使用约定 this.fieldName = fieldName
进行设置。你会注意到 eclipse 并没有坚持这个设置器。
仅供参考:当我将 getter 更改为 getContentsFrag() 并引用它 .contentsFrag 时,这一切都非常有效。
I have mysterious happenings in my code. Here's the snippet from the bean:
public List<HelpContentsFrag> getCFrags()
{
return cFrags;
}
public void setCFrags(List<HelpContentsFrag> frags)
{
cFrags = frags;
}
Here's the snippet from my view code (tag file)
cFrags:[${topic.cFrags}]
where topic is an object of the bean type.
Here's the error:
javax.el.PropertyNotFoundException: Property 'cFrags' not found on type com.company.beans.BeanClass
One additional thing to consider. There is a subtle difference in the eclipse-generated setter. Apparently, it didn't like the name cFrags either. The field name is cFrags and with every other setter I get parameter with the same name as the field and it is set using the convention this.fieldName = fieldName
. You'll notice that eclipse did not stick with that on this setter.
FYI: this all works great when I change the getter to getContentsFrag()
and reference it .contentsFrag
.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我相信你想要:
大写的 C。请参阅 JavaBeans Spec:
I believe you want:
With a capital C. See JavaBeans Spec:
引用 JavaBeans 规范(最后更新于 1997 年) :
这描述了方法名称如何转换为属性名称。不太清楚的是 Introspector 产生也由属性->方法查找使用的单个表。
您已经发现了一种避免该问题的方法。另一种方法是创建一个 BeanInfo 类,其中包含正确的属性->方法映射(
Introspector
文档描述了如何执行此操作)。To quote the JavaBeans specification (last updated in 1997):
That describes how method names are converted to property names. What's not so clear is that the Introspector produces a single table that's used by property->method lookups as well.
You've already discovered one way to avoid the problem. Another is to create a
BeanInfo
class that contains the correct property->method mappings (theIntrospector
doc describes how to do this).