Monday, December 27, 2010

I have settled on a new platform for webapps

Here it is: Play! Framework, Squeryl, and Scalate.

Getting them to work well together was a bit of a challenge. Play! has a collection of modules in different states of development. I got the best results using the most recent releases at the moment: play 1.1, play-scala 0.8, and squeryl 0.9.4RC3. The most recent scalate module 0.7.2 was too old, and I had to use the development version from github and compile it myself.

Here is one issue I run into:

Given an example controller and action:
object Manage extends ScalateController {
  def index = {
    val someVar = getSomeObjectFromSomewhere()
    Template(someVar) 
  }
}

The syntax hints that Template is an object that gets returned by the action. This is actually not correct. Play takes a bit of a strange approach when handling results in the controller. Result objects inherit from RuntimeException and are "thrown" from a controller's action and they are caught by framework. I suppose it makes it easy to break out of the flow in order to redirect, or something like that. So Template() is actually a method that "throws" a Result object.

This made it difficult at first to work with squeryl, which expects all database access to wrapper on a transaction{} block. For a whole day I kept trying to find the right way to do that trying different versions of the modules and different rendering methods. This was one of my attempts:

object Manage extends ScalateController {
  def index = transaction {
    // some squeryl database stuff 
    Template() 
  }
}

Of course it didn't work since the thrown results breaks the transaction. Then I created a base class that would catch and re-throw the result, something like this:

class MyBaseController extends ScalateController {
  def Template (_args:Any*) {
    var e:Result = null
    transaction { 
      try {
        super.Template(_args:_*)
      } catch {
        case r:Result => e = r
      }
    }
    throw e
  }
}

But that broke the "magic" parsing of local variables to send to the templates (maybe play does a little too much magic sometimes).

Finally I realized squeryl has a way to bind a session to the thread without using the transaction method. So, I was able to use that method and an @Before annotation to get the code to work:

class Manage extends ScalateController {
  @Before 
  def initSquerylSession = 
    SessionFactory.newSession.bindToCurrentThread

  def index = { 
    val projects = from(Repo.projects)(p => 
      where(p.public === 1) 
      select(p)
    ).toList

    Template(projects)
  }
}

Hopefully this post will save someone some time.

Friday, December 10, 2010

Gravity: Project Pages

I am currently working on a new Gravity feature called Pages. As you probably guessed from the name, it will allow users to create "Pages" (documents) for their projects. It is the first Gravity feature built using S2JS so I am pretty excited. All of the interactivity (javascript) is actually being written in Scala and it is working great.

I will also use the new feature to document S2JS. So it has been a great feature to test this project with. I'll keep you posted of when it will be available.

S2JS: Scala to Closure-annotated Javascript

For the last few months I've been working on a project called S2JS. The source code for the project is currently hosted at github: https://github.com/alvaroc1/s2js

S2JS is a Scala compiler plugin that can turn a subset of Scala code into Closure-annotated Javascript Code.
Currently it is a work-in-progress, although I am currently using it for some of the features on GravityDev.com.

Closure compiler/library

For those not familiar with the closure library/compiler, it allows you to annotate your javascript with type annotations, turning Javascript into a typed language. With those annotations in place (plus the equivalent of imports) you can run the closure-compiler to perform TONS of optimizations like inlining and removal of dead code.
After using it for a while I came to the conclusion that it is has a lot of performance benefits, but it is extremely verbose and repetitive.

Scala / Javascript

As you probably know, Scala is a VERY nice statically-typed language that compiles to the JVM. At first glance it seems very different from Javascript, but it turns out it is not so different from Closure-annotated-javascript: They are both statically-typed and they both have classes, singleton objects, anonymous functions, structural types, generics, etc. So it made sense to create a way to translate Scala code (terse and expressive) to Closure-annotated Javascript (very verbose).

Other Approaches

I have seen other projects that aim to turn Scala code into Javascript code, but I think that specifically targeting the closure compiler yields the most benefits. Most of the type information that the closure compiler wants (as annotations) is readily available within the AST of a Scala program.

Programmers are gods

I have the view (borrowed from Programming the Universe by Seth Lloyd) that the universe is just one huge computation.

I like to think that that means we programmers are like gods :)