I’ve been using Lift and Scala for a few weeks now to build my scala job site. I’ve been incrementally adding features ever since I first opened the site a week ago. Two of those features I added today involved utilizing the runtime environment support in Lift, so I thought I’d write up a quick tutorial on how you can use it. Making your web application behave differently based on whether it is in development or production is incredibly important, and fortunately Lift makes it easy.

The first thing I had to add was a Google AdSense ad box. My designer left room for ads on the website, but I didn’t initially implement them and instead just mapped them to a snippet that returned a comment. Now I’d like to put the ads on the page so I can start earning my internet millions. However, I don’t want them to show in development mode because they will throw off my stats and because Google and/or the advertisers don’t appreciate me racking up thousands of ad impressions while developing my own site. Let’s see how we do this:

def ad(in: NodeSeq) : NodeSeq = net.liftweb.util.Props.productionMode match {
      case true => <real adsense code goes here />
      case false => <!–Google Ad Goes Here–>
}

This calls the funcion productionMode on the Props class that is part of Lift. This tells us whether we are in production or not - if true, it will show an ad, otherwise it just sticks a comment in the HTML. But, how does Lift know if we are in production or not? Good question. When you run the application you can tell it what environment you are in by setting the run.mode property. If you run Lift with mvn jetty:run, it will assume you are in the default (development) environment. If you run Lift with mvn jetty:run -Drun.mode=production, it will assume you are in production. On my production Tomcat server that this app runs on, I just added a startup property to set the run mode to production.

Now let’s move to something a little more complicated. Whenever a new job is posted, I want to update the Twitter status for my site (@scalacareers) so that everyone following it will know that there is a new job to check out. In development mode, I don’t want to post to the same Twitter account, though, as that would really confuse and frustrate my followers! I created another account (scalacareersdev) that my app will use in development, but how do I make sure the app is using the proper account? Here is where the property support comes to the rescue. Lift will load property files based on my environment - it will look in /default.props for the default (development) mode, and in production.default.props for production. So I create both of these files, and in default.props I put:

twitter.account=scalacareersdev
twitter.password=devpassword

in production.default.props, I use:

twitter.account=scalacareers
twitter.password=realpassword

Now, how do we use these? I have a twitter actor that updates the status:

val session = new AuthenticatedSession(“scalacareers”, “realpassword”)
session.updateStatus(“New Scala job posted - “ + job.jobTitle + ” - more info at: “ + job.buildUrl)

I just need to refactor it to not have a hardcoded username/password, and instead get the values from the Props class:

val account = Props.get(“twitter.account”).open_!
val password = Props.get(“twitter.password”).open_!

This will look up the properties correctly for the environment, and I will be posting to the proper Twitter account. Note that by using open_!, my app will fail if the properties aren’t there, which is probably sensible in this case.

As you can see, the property support in Lift is quite easy to use and is incredibly useful when you have functionality that needs to change based on the environment.