Last week I did a presentation on NoSQL at bol.com. In order to make it a little bit more compelling, I figured I would throw in a demo on how to use MongoDB for real - but I obviously didn't feel like doing it using Java.
So, behold, here is the entire catalog.
Okay, it's just a single page, but the first lesson learned is that the combination of Scalatra, SBT and MongoDB gives you a lot of bang for the buck.
Now, I could easily imagine that it is quite hard to digest everything in a single go, so I am going to explain a couple of things.
Lesson learned 2: Dealing with exceptions
One way of dealing with exceptions in Scala is to use a try-catch block. I am not even going to discuss that, because it's pretty much the same as in Java, apart from the fact that in Scala it's less code.
In my particular case however, I had to see if some parameters would be present in the request. I could have created a complicated conditional block containing a try-catch block to capture NumberFormatExceptions, but that would be a lot of code.
Instead I did this:
So, behold, here is the entire catalog.
import javax.servlet.ServletConfig
import com.mongodb.casbah.Imports._
import scala.xml._
import org.scalatra._
import scala.util.control.Exception._
class WebApp extends ScalatraServlet {
val missing = "http://cdn2.iconfinder.com/data/icons/august/PNG/Help.png"
val mongo = MongoConnection()
val coll = mongo("amazon")("products")
get("/products") {
val numberFormat = catching(classOf[NumberFormatException])
val limit = numberFormat opt request.getParameter("limit").toInt
val offset = numberFormat opt request.getParameter("offset").toInt
<html>
<head>
<style type="text/css">
body {{ font-family: Calibri; }}
</style>
<title>Products</title>
</head>
<body>
<ul>
{
val items = coll.find().limit(limit getOrElse 10).skip(offset getOrElse 0)
for (item <- items) yield {
val set = item.as[DBObject]("ItemAttributes")
val authors = set.getAs[BasicDBList]("Author") map(_.mkString(", ")) getOrElse("No authors")
val title = set.as[String]("Title")
val publisher = set.getAs[String]("Publisher") getOrElse("No publisher")
val img: String = item.getAs[DBObject]("SmallImage") flatMap(_.getAs[String]("URL")) getOrElse(missing)
<li>
<img src={img}/>
<b>{title}</b>
<span> ({publisher})</span>
<em> {authors}</em>
</li>
}
}
</ul>
</body>
</html>
}
}
Okay, it's just a single page, but the first lesson learned is that the combination of Scalatra, SBT and MongoDB gives you a lot of bang for the buck.
Now, I could easily imagine that it is quite hard to digest everything in a single go, so I am going to explain a couple of things.
Lesson learned 2: Dealing with exceptions
One way of dealing with exceptions in Scala is to use a try-catch block. I am not even going to discuss that, because it's pretty much the same as in Java, apart from the fact that in Scala it's less code.
In my particular case however, I had to see if some parameters would be present in the request. I could have created a complicated conditional block containing a try-catch block to capture NumberFormatExceptions, but that would be a lot of code.
Instead I did this:
val numberFormat = catching(classOf[NumberFormatException])
val limit = numberFormat opt request.getParameter("limit").toInt
val offset = numberFormat opt request.getParameter("offset").toInt
First I defined an object called number format by calling a factory method on the Exceptions object, passing in the type of exceptions I want to have handled. The object returned is giving me several options for handling blocks of code that will generate these exceptions. The method I am using here is opt.
The 'opt' method takes a by-name parameter that will be evaluated by the operation itself. Once it is evaluated, it will wrap the result into a Some, and return that Option. That is, unless the NumberFormatException occurred. In that case it will return a None. And later on, I am calling getOrElse(...) on that option, to supply a default value in case it is a none.
So in terms of Java, I am doing this:
int limit = 0;
try {
limit = Integer.parseInt(request.getParameter("limit"));
} catch (NumberFormatException nfe) {
limit = 10;
}
The whole construct in Scala is getting reduced to:
val limit =
(numberFormat opt request.getParameter("limit").toInt) getOrElse(10)To me, that looks a lot more sensible. The entire policy for dealing with the exception has now been encoded in a library class.
Lesson learned 3: Accessing MongoDB from Scala is Easy
Accessing MongoDB from Scala seems pretty easy. The Casbah library makes it easy. One of the things that I found a little hard to grasp at first is what to expect from the object model returned from MongoDB. If you don't have a clue what the MongoDB Java drivers would have normally returned, then figuring out what to expect from Casbah can be a little challenging. I think I'm getting the hang of it now though.
These expressions might seem a little bewildering at first:
val publisher = set.getAs[String]("Publisher") getOrElse("No publisher")
val img = item.getAs[DBObject]("SmallImage") flatMap(_.getAs[String]("URL")) getOrElse(missing)
but actually Scala is helping a lot in these cases. In my database schema, a lot of fields are optional. In Java, you would have no other option than getting the value, storing it in a variable, checking if it is null, and then continuing based on the outcome. If your data is tugged away deeply into your document, then you would have pages of code in no time.
In Scala, with Scala's support for Options, it is actually quite easy. No need to capture results in variables before being able to move on. The Option allows you to keep on chaining operations to the result of previous operations. (By the way, the flatMap operation on the second line is going to make sure that instead of getting an Option[Option[String]], I end up getting an Option[String]. On that result, I can invoke getOrElse and pass a default value.)
Lesson learned 4: Scalatra is simple
In all honesty, I have only scratched its surface, and it's questionable if you would ever create a huge web application this way, but it really is a 'hit-the-ground-running' experience.
Lesson learned 5: SBT makes it even sweeter
This is the way it works. You start sbt, and then type:
jetty-run ~prepare-webapp
From that point on, SBT will examine changes in your sources, and for every change immediately recompile your code and replace the existing web app. Way faster than you would imagine.
No comments:
Post a Comment