Template does not evaluate variables with first letter lowerCased and second...
Generates text that depends on changing data (like dynamic HTML).
Brought to you by:
revusky
I have fields in the model defined as:
private String name;
private String xQuery;
with getters:
public String getName()...
public String getXQuery()...
Freemarker is not able to evaluate xQuery by calling ${model.xQuery!"missing"}, but ${model.XQuery!"missing"} works.
When evaluating name, everything is OK: ${model.name!"missing"} works.
Why there is a need for the upper cased first letter when the second letter is also upper cased?
To put it simply, it's like that because the JavaBeans specification says so. As of the details, the root of the whole mess is that the camel case convention that Java uses is broken, as it requires you to keep the orignal case of the words, except that you convert the first letter to upper case. Like, you meant to write
getHTML()
, not the correct camel case form,getHtml()
. Using your logic now we would haveobj.hTML
, which is of course even worse thanobj.HTML
. And so the JavaBeans specification says, that if you have consecutive upper cases letter, you can't lowercase the first letter.Last edit: Dániel Dékány 2014-09-30
Hi Daniel,
thanks for Your answer. You are right, XQuery should have first two letters upper cased. I gave wrong example. But imagine situation when the variable is called "iPhone". Using freemarkers ${model.iPhone!"missing"} it would print "missing". Or the getter would have to be getiPhone().
This matter is decided by the JavaBeans specification, not FreeMarker. Pretty much everything out there builds on that specification. You can provide a
BeanInfo
class though, where you can explicitly tell the name of the JavaBean properties.OTOH, maybe FreeMarker should provide a way to deviate from the specification, like, accepting both
obj.IPhone
andobj.iPhone
forgetIPhone()
, but that's then an RFE, not a bug.Ticket moved from /p/freemarker/bugs/416/
Ticket moved from /p/fmpp/feature-requests/29/
Changed this to an RFE.
There are some other tickets that have problems with
java.beans.Introspector
, so maybe we should push our own implementation as an option: https://sourceforge.net/p/freemarker/feature-requests/92/, https://sourceforge.net/p/freemarker/feature-requests/94/