Richard Dallaway
Squeaky Clean Ajax and Comet with Lift
Focus on application development, not the plumbing
Lift is a web framework for Scala, and is probably best known for having great Comet and Ajax support.
I’ve been touring the features of Lift that I find appealing. Initially I looked at designer-friendly templates and REST services. Recently, I highlighted the great features for organising and controlling access to content.
Let’s now take a look at the Ajax and Comet features of Lift.
Ajax
When I think of Ajax, I think of interacting with a web server, but avoiding page reloads.
An example: suppose we had a site that allowed you to write poems, and a feature on that site might be a button you could click to get an associated word from a thesaurus. The thesaurus we have is large, we don’t want it loaded in the browser, so we need to call the server to use it.
The HTML template would be a field and a button:
<div data-lift="Associate">
<input id="word" type="text" placeholder="Type a word">
<input type="submit" name="submit">
</div>
So far, that’s probably similar across many web frameworks. What you might now expect is for us to define a REST endpoint, do some jQuery wiring to connect the service to the button.
In Lift, we can do that, but often the Ajax goodness comes via this kind of Scala code:
class Associate {
def render =
"@submit [onclick]" #> ajaxCall(
ValById("word"),
w => SetValById("word", Thesaurus.association(w))
)
}
This Associate snippet is binding the submit button’s click event to a Lift Ajax call. That is, the left side of the replace function (#>) is a CSS selector targeting the “onclick”, and the right side is arranging for the Ajax call to hit the server.
The first parameter to ajaxCall is the value passed from the browser to the server. We’ve asked for the value of the input field with an ID of “word”. The second parameter is the function to run when the button is pressed. Here we’re taking the word we’ve been sent, and updating the field with whatever our Thesaurus.association function gives us back.
Read more…
A Birds-eye View with Lift
Organize and control content with the Lift web framework
Lift is a web framework built for the Scala programming language, running on the Java Virtual Machine. Version 2.5 recently shipped, and I’m highlighting features of the framework that I find appealing.
Last time it was transforms and REST services, and this time it’s two features around organizing and controlling access to content.
SiteMap
How do you manage the HTML pages on site? Maybe some pages are available to everyone, others require login or some condition for access, and often pages are grouped in some way. Lift has an optional mechanism for expressing all this in one place, and it’s called SiteMap. This is how it looks in code:
lazy val home = Menu.i("home") / "index"
lazy val poets = Menu.i("poets") / "list" submenus (
Menu("Larkin") / "a-z" / "larkin",
Menu("Tennyson") / "a-z" / "tennyson"
)
LiftRules.setSiteMap(SiteMap(home, poets))
We’ve defined a site made up of a home page, and pages for poets we like. Why is this a good thing?
First, it’s a pretty readable representation of the site in (compiler checked) Scala code. You can probably figure out that we have a page called “home” found at /index.html (or / as it’s usually known).
What might not be obvious is that Menu.i is using “home” as a key into your translation resources, meaning the link text will be the localized version—if you’re building an internationalized site. The link to the page can be generated by a Menu.builder, a snippet you can use on pages to give your users navigation of the SiteMap.
The second menu item is called “poets,” served up from a template called list.html. On the home page, the navigation snippet would give you a link to the “poets” page, but by default is smart enough to hide the submenus until you visit the list of poets.
SiteMap also performs access control: if you use SiteMap, HTML pages have to be listed in it to be accessed. It’s a simple line of defense, but you can improve on this by adding location parameters. These are rules for controlling access to a page.
Let’s say we wanted to only offer some content to customers paying for our premium plan:
val PremiumCustomersOnly = If(
() => false,
() => S.redirectTo("https://shop.example.org/") )
This is an if-then-else construct, made up of two functions. The first function is a test for what qualifies as a premium customer. It’s an arbitrary computation, and in this example it’s false, meaning nobody is a premium customer (in reality, we’d perhaps check a property of the logged user). If you nevertheless try to get to the page, the second function kicks in, and you’d be sent to our store front.
We can apply the “premium customer” rule to any part of the site, but we’re going to just restrict Tennyson poems:
Menu("Tennyson") / "a-z" / "tennyson" >> PremiumCustomersOnly
If you don’t like the >> method name, use rule instead. If you just don’t like this domain specific language (DSL), you can construct a SiteMap in longer-form method calls.
What’s great about SiteMap is the flexibility it gives you: if you can’t get the behavior you want out of the box, you can write custom functions and classes, and drop them into the SiteMap. If you want menus displayed in a completely different way, not handled by Menu.builder customization, you can write a different navigation snippet. Location parameter rules allow you to isolate logic, and combine them as needed to parts of your site.
The Appeal of the Lift Web Framework
The extreme end of weird (as far as web frameworks go)
Lift is one of the better-known web frameworks for Scala. Version 2.5 has just been released, so it seems like a good time to show features of Lift that I particularly like.
Lift is different from other web frameworks (in fact, I labeled it at the extreme end of weird in the first presentation I gave about it), but people who get into Lift seem to love the approach it takes. It’s productive and enjoyable, which goes well with Scala.
I’ll keep this post short. Just two things:
Transforms
You might be familiar with an MVC approach to the Web, where you have code that forwards to a view, and in that view you maybe use a little bit of mark-up to loop or display values. That’s not how it goes in Lift.
Instead, you start with the view first, and use HTML5 attributes to mark the parts of the view that need transforming. Here’s an example:
<p data-lift="Poems"> The work of <span class="author">someone</span> includes <span class="title">something</span>. </p>
That’s valid HTML5. You can view it in your browser, or edit it in Adobe Fireworks, or whatever tool you want. The only part of it that looks a little strange is the data-lift attribute. What that’s doing is naming a Lift snippet, and a snippet is just a class. It might look like this:
package code.snippet
import net.liftweb.util.Helpers._
class Poems {
def render =
".author *" #> "Philip Larkin" &
".title *" #> "This Be The Verse"
}
What’s going on here? We’re using a nifty DSL in Lift to transform the <p> tag so that it contains the content we want. We’re saying…