Zach's Blog

You’re building a web site and the designers send you XHTML templates with essentially the same form on two different pages, but each page uses a slightly different layout. Being the good coder you are, you want to reuse the same submit-handling code on the back-end to prevent code duplication. This is easy to handle using Lift snippets.

The form lets a user add a new restaurant to our restaurant review site. So we create a snippet like this (it just prints the submitted data for now):

import scala.xml._
import net.liftweb.util.Helpers._
import net.liftweb.http._

class CreateRestaurant {
  def render(xhtml: NodeSeq): NodeSeq = {
    var name = ""
    var address = ""
    var phone = ""

    def createRestaurant() = println("Created " + name + ", " + address + ", " + phone)

    bind("form", xhtml, "name" -> SHtml.text(name, name = _),
                        "address" -> SHtml.text(address, address = _),
                        "phone" -> SHtml.text(phone, phone = _),
                        "submit" -> SHtml.submit("Add", createRestaurant))
  }
}

Next we can create two different forms in our XHTML templates and bind them to the same CreateRestaurant snippet. We are free to modify the design inside the snippet, as long as we bind the same form elements in each one.

Here’s the first form template:

  <lift:CreateRestaurant form="POST">
    <h3>Add a new restaurant</h3>
    <table>
      <tr><td>Name</td><td><form:name><input type="text"/></form:name></td></tr>
      <tr><td>Address</td><td><form:address><input type="text"/></form:address></td></tr>
      <tr><td>Phone</td><td><form:phone><input type="text"/></form:phone></td></tr>
      <tr><td></td><td><form:submit><input type="submit"/></form:submit></td></tr>
    </table>
  </lift:CreateRestaurant>

And here’s the second form template:

  <lift:CreateRestaurant form="POST">
    <table>
      <tr>
        <th>Name</th>
        <th>Address</th>
        <th>Phone</th>
        <th></th>
      </tr>
      <tr>
        <td><form:name><input type="text"/></form:name></td>
        <td><form:address><input type="text"/></form:address></td>
        <td><form:phone><input type="text"/></form:phone></td>
        <td><form:submit><input type="submit"/></form:submit></td>
      </tr>
    </table>
  </lift:CreateRestaurant>

Same form, just different layouts: the first has the fields arranged horizontally while the second lays them out vertically. When Lift renders them they both look different but behave exactly the same way on the back-end, because they both reuse the same snippet code.

No more need to duplicate back-end form submit handling code!

One of the awesome features of “view first” web frameworks like Lift and Wicket is that the page templates are stand-alone documents that are viewable without being served by the framework and don’t contain any server-side code.  This makes things much easier for web designers: they can create an XHTML template file using whatever tool they want and then you just sprinkle in some additional elements.  In a Model 2 framework (like Rails or countless others) your templates are rarely viewable right in a web browser: they’re chopped up to pieces and contain lots of logic in Ruby/PHP/Java/whatever.

In the Lift Book and most Lift code samples, the templates aren’t really useful outside of the framework because the Lift elements are all empty.  For example, consider this snippet that displays an account’s balance at a certain time:

<lift:Ledger.balance>
  <ledger:balance/> as of <ledger:time/>
</lift:Ledger.balance>

When this is displayed in a browser right off of the file system, you don’t really see anything meaningful:

Instead, we can put some dummy data into this template to make it display a little more realistic on its own:

<lift:Ledger.balance>
  <ledger:balance>$2500.00</ledger:balance> as of <ledger:time>8 Aug 2009 11:43am</ledger:time>
</lift:Ledger.balance>

Typically, a web designer will give you a file more like this one, to which you will add your own lift tags.  But your lift tags are simply ignored by the browser, so viewing the template right off your file system works fine.

If you don’t have web designers involved in your project there probably is no point in using all of this dummy data in the templates.  But if web designers are building the template files, it’s very useful to include it.