Common lift gotcha’s

Going to keep this here so maybe others will find this usefull as well and I will adding more gotcha’s here as I ran into them. So this basically is an overview to my thickness to understand lift correctly 🙂

lift Error locating template Message: Expected ‘;’
What this means is, that I copied an example of a snippet that does not work (anymore) on my computer. Using scala 2.8.1 and lift 2.2, the example of the simply lift website is like this:
<div id="main" class="lift:surround?with=default&at=content">

However it should be:
<div id="main" class="lift:surround?with=default;at=content">

Notice the amp between default and at was changed into a ‘;’

valMinLen method
As part of the validations that mapper has enabled (and are very convenient to use), there is a validation that checks if the length of a string is at least x characters long. You can enable this like this:
override def validations = valMinLen(5, "Your login name should be at least 5 chars") _ ::
valUnique("login name already exists") _ ::
super.validations

The valMinLen validation will check to see if the string is at least 5 characters and then the valUnique will check the database to see if an object with this login name already exists. However I also tried to check that the field should not be empty and thus changed the validations for another field to:
override def validations = valMinLen(0, "Can not be empty") _ ::
valUnique("name already exists") _ ::
super.validations

But now nothing was happening anymore. No validations were added when I created an object with an empty name. The solution was simple, but took me a few hours of looking around to find it.
override def validations = valMinLen(1, "Can not be empty") _ ::
valUnique("name already exists") _ ::
super.validations

1 was the happy number, and that makes sense since it says that it should be at least one character now, so not empty. I was looking at this problem with too much of a java perspective, where the content of a string is considered empty if it contains 0 characters.

error: value #> is not a member of java.lang.String
add an import statement:
import net.liftweb.util.Helpers._

Resources dont like dots
It is rather easy using i18n resources in lift. For the menu options you use the
Menu.i("Home")
which will be looked up in the _resources.html and you can also add resources per page and for each locale. Note that the resource keys are case sensitive, so Menu.i(“home”) should not have worked.

However what the resources dont seem to like (and what the simply.liftweb.net site does not tell) is that there should be no dots in the resources, for instance this resource file:
<resources>
<res name="Home">E.T. call home</res>
<res name="caller.id">E.T.</res>
</resources>

When using the resouce for home, there will be no problem but caller.id will not be replaced. Replacing the dots with underscores does work though, so
<span class="lift:Loc.caller_id">Mr T.<span>
will replace Mr T. with E.T.

Shy away from java camel case varsCheck your html5 properties

I had created a small snippet containing the following code
<tr class="lift:Employees.list">
<td><employee:name/></td>
<td><employee:editLink/></td>
</tr>

However the editLink refused to be shown. When I looked at the html code I noticed that the editLink was replaced by a editlink tag which was not resolved. In my snippet code I had added a editLink bind parameter, but apparently the system was looking for editlink with a small ‘l’. Replacing the editLink on the snippet with editlink did the trick. Probably is some configuration somewhere, but I can’t seem to find where that is. For now, I will just create all bind vars without capitals. And indeed, this is a setting in the boot.scala. Once you instruct lift to use html5 settings then it will convert all camelcases to lowercase words. You can prevent this by setting the following property in boot.scalaLiftRules.htmlProperties.default.set((r: Req) =>
new XHtmlInHtml5OutProperties(r.userAgent))

2 thoughts on “Common lift gotcha’s”

  1. Thank you for your help, I’m still beating up with those same caveats…

  2. Thanks for the hints! Saved me some time when I ran into the #> not a member of String -problem.

Comments are closed.