JavaBeans and JSP EL
Conversion rules for attribute names
Intro
"Naming conventions make programs more understandable by making them easier to read. They can also give information about the function of the identifier-for example, whether it's a constant, package, or class-which can be helpful in understanding the code."
(http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367)
Java naming conventions suggest using firstWordLowerCaseButInternalWordsCapitalized for instance variable names.
JavaBeans classes need to follow the above rule and provide accessor and mutator (get/set/is) methods to the beans' properties (attributes). This allows tools to easily discover the attributes and the methods.
Classes that follow the JavaBeans convention can be easily used in JSP pages using the JSP Expression Language (EL):
"The dot operator is typically used for accessing the properties of an object. In the expression
(http://www.ibm.com/developerworks/java/library/j-jstl0211.html)
JSP EL
I've been following this convention in my model classes, which allowed me to use JSTL and the Spring tag libraries as well as avoid having to use "untestable" scriptlets!
(http://static.springframework.org/spring/docs/2.0.x/reference/mvc.html)
Recently I've spent a few hours trying to figure out an odd exception.
The exception looked something like this:
But the code looked OK!
What was going on here?
Eventually, I've tried renaming the attribute to ibuttonCode in the class file and the JSP file.
It all worked fine! No more complaints!
After a bit of searching on the web and the specs I've found this in the JavaBeans 1.01 spec (8.8 Capitalization of inferred names.):
"However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone."
And later:
"We provide a method Introspector.decapitalize which implements this conversion rule."
(http://java.sun.com/javase/6/docs/api/java/beans/Introspector.html#decapitalize(java.lang.String))
In the Introspector Javadoc:
"Thus "FooBah" becomes "fooBah" and "X" becomes "x", but "URL" stays as "URL"."
I can only imagine that the original requirement was for JavaBeans to be able to deal with abbreviations and acronyms.
It seems that a probable "shortcut" to this requirement lead to a rule and an implementation that only checks the first two characters!
Who knows..?
IMO this rule's exception ought to have been included in most naming convention documents. Especially in any JSP EL documentation!
Conclusion
JSP EL (with JSTL or other tag libraries using EL) doesn't work very well with "cool" attribute name prefixes like "i", "e", "x", etc. as in eCommerce, xFactor, iPod!
"Naming conventions make programs more understandable by making them easier to read. They can also give information about the function of the identifier-for example, whether it's a constant, package, or class-which can be helpful in understanding the code."
(http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367)
Java naming conventions suggest using firstWordLowerCaseButInternalWordsCapitalized for instance variable names.
JavaBeans classes need to follow the above rule and provide accessor and mutator (get/set/is) methods to the beans' properties (attributes). This allows tools to easily discover the attributes and the methods.
Classes that follow the JavaBeans convention can be easily used in JSP pages using the JSP Expression Language (EL):
"The dot operator is typically used for accessing the properties of an object. In the expression
${user.firstName}, for example, the dot operator is used to access the property named firstName of the object referenced by the user identifier. The EL accesses object properties using the Java beans conventions, so a getter for this property (typically a method named getFirstName()) must be defined in order for this expression to evaluate correctly."(http://www.ibm.com/developerworks/java/library/j-jstl0211.html)
JSP EL
I've been following this convention in my model classes, which allowed me to use JSTL and the Spring tag libraries as well as avoid having to use "untestable" scriptlets!
(http://static.springframework.org/spring/docs/2.0.x/reference/mvc.html)
Recently I've spent a few hours trying to figure out an odd exception.
The exception looked something like this:
javax.servlet.ServletException: An error occurred while evaluating custom action attribute "value" with value "${device.iButtonCode}": Unable to find a value for "iButtonCode" in object of class "Device" using operator "." (null) But the code looked OK!
private String iButtonCodeand:
public String getIButtonCode()
{
return iButtonCode;
}
public void setIButtonCode(String iButtonCode)
{
this.iButtonCode = iButtonCode;
}
...${device.iButtonCode}...
What was going on here?
Eventually, I've tried renaming the attribute to ibuttonCode in the class file and the JSP file.
It all worked fine! No more complaints!
After a bit of searching on the web and the specs I've found this in the JavaBeans 1.01 spec (8.8 Capitalization of inferred names.):
"However to support the occasional use of all upper-case names, we check if the first two characters of the name are both upper case and if so leave it alone."
And later:
"We provide a method Introspector.decapitalize which implements this conversion rule."
(http://java.sun.com/javase/6/docs/api/java/beans/Introspector.html#decapitalize(java.lang.String))
In the Introspector Javadoc:
"Thus "FooBah" becomes "fooBah" and "X" becomes "x", but "URL" stays as "URL"."
I can only imagine that the original requirement was for JavaBeans to be able to deal with abbreviations and acronyms.
It seems that a probable "shortcut" to this requirement lead to a rule and an implementation that only checks the first two characters!
Who knows..?
IMO this rule's exception ought to have been included in most naming convention documents. Especially in any JSP EL documentation!
Conclusion
JSP EL (with JSTL or other tag libraries using EL) doesn't work very well with "cool" attribute name prefixes like "i", "e", "x", etc. as in eCommerce, xFactor, iPod!