chrislewis's posterous

IE's conditional comments are simultaneously the warts of a fragmented web and a refuge for weary web developers. If you want to deliver a hack-free, consistent(ish) and cross-platform experience to your user's you most likely find yourself using them. When running in the Production run mode, Lift removes all (x)html comments (in all modes except Development, in fact). This poses a hurdle if you are in the aforementioned category of developers (and you should be).

Like most things in lift, this behavior is easily modifiable, but finding out where and how may not be so obvious. Here's how to enable comments in the Production run mode via Boot: 

package bootstrap.liftweb

class Boot {

  def boot {
    // I want conditional comments.
    LiftRules.stripComments.default.set(() => false)
  }

}

Much of Lift's behavior is dictated via LiftRules, so when in doubt, check there.

Lift supports run modes, a feature which makes it easy to tweak the application depending on its environment. This is useful for enabling/disabling features, changing things like a system's sending email account, rendering a google analytics javascript block, et cetera. In Lift this mode is dictated by the run.mode system property which, in some environments, can be a bit painful to change.

For App Engine, however, there is a simple solution: bind Lift's mode directly to the GAE environment:

package bootstrap.liftweb

class Boot {
  def boot {
    
    System.setProperty("run.mode",
      System.getProperty("com.google.appengine.runtime.environment"))
      // the rest of your configuration... 

  }
}

GAE supports local development through a local server, complete with working and faux services. Using appengine-web.xml you can configure system properties, but there isn't a simple way to vary these settings according to the GAE environment (perhaps a resources plugin for sbt is in order...).

However, GAE, like Lift, identifies its environment using a system property. Incidentally, the two settings it uses align with Lift's run modes: Production and Development.

I arrived at the FGM building by way of my couchsurfing host, Jenny. At the moment, Reston looks a bit like London (at least if you look straight up). Fall has painted the leaves brilliantly, a sight I’m left wanting in Florida.

Jenny graciously dropped me off at the FGM building on her way to school (she’s a school teacher). I gladly accepted arriving an hour early for a free ride, and so I just started wandering the office park. I stumbled on this office “cafe” as it were, and here I sit. I seem to be just outside a free guest wifi network, but that’s ok. For a first-timer at an unconference, or any tech conference for that matter, I feel fairly prepared.

I’ve just made my way into the FGM suite. So far we’re about 32-30 strong!

Lift provides a trait called ProtoUser, which helps you in quickly adding base functionality to your application for user-specific data. The Lift book mentions this class very briefly, but it makes the assumption that the reader will be to intuit how to complete the example code to have a base starting point. Here’s what you must have (assuming this is in the model directory):

package app.model

class User extends ProtoUser[User] with LongKeyedMapper[User] {
def getSingleton = User
}

object User extends User with LongKeyedMetaMapper[User]

You need to mix in the LongKeyedMapper trait, and you need the User singleton.