Bubble Foundry

Quick note for fellow Lift developers: I was happily using a Menu.param when I decided to use a Menu.params instead (see the ScalaDocs) in the hopes of both more descriptive URLs and less to calculate on the actual page. While implementing it wasn’t too hard, my new URL pattern for the menu entry was a little complicated:

Menu.params[MyObject](
  ...
) / "something" / * / * / "to" / *

I had a something.html Template but it wasn’t getting picked up and I was getting a weird 0 (yes, zero) status code returned when I requested the page, with the MyObject being initialized correctly.

The solution I came up with was to manually specify the Template for the Menu:

Menu.params[MyObject](
  ...
) / "something" / * / * / "to" / * >> Loc.Template(
  () => Templates(List("comparison")) openOr <div>Couldn't find template</div>
)

Thought it was worth sharing…

Reposting from the Lift mailing list.

For some time know I’ve been thinking about how cool it’d be to be able to essentially write Javascript but with all the Scala goodiness behind the scenes. Lift already has abstractions for more common Javascript language elements, so I have suspected that it could be used as the basic for something that looked more like plain Javascript.

This evening I was looking at PhantomJS and realized that to use it for the type of work I need I would have to control it with lots of Javascript files generated on the fly. So, I finally sat down and hacked around. This is what I’ve come up with:

As you can see, for Javascript language features I’ve basically just put j_ before what are also reserved words in Scala. So, JsFalse becomes j_false. The same is true for break, continue, and return.

As you can see with j_if and j_for, those case classes are declared such that you get a more natural syntax, one approaching Javascript’s. For instance, you can directly call a JsVar with 0 to n parameters, without writing Call("var_name", params0, ...). I guess that the experimental Dynamic trait could be added to the pimped JsVar (RichJsVar, of course) but that’s probably going a bit far! ;-)

I’ve also added a bunch of implicits, both for my pimped classes but also to convert JsCmd to JsExp. Lift already has a conversion the other way around but there isn’t one in this direction. I’m not sure if there is no implicit for a good reason. Perhaps this will break things?

Where is this wonderful code, you ask? Why, it’s a simple Gist: https://gist.github.com/1028437!

I look forward to your comments!

The canonical – I’m making a leap to say that, but why not – way to add REST APIs to a Lift app is to append them to one of the app’s dispatch tables, either stateful or stateless. David and Tim have examples of using them to ensure a user is logged in, however both their examples do so by checking an existing SessionVar.

Here’s how to do so using only information in the request, specifically checking HTTP Basic authentication information against a database:

/*
 * In the companion object of my Mapper model
 */
// code to authenticate stateless API requests (see Boot.scala)
def reqPasses(req: Req): Boolean = {
  // hack to get access to the class' credentials method
  val auth = HttpBasicAuthentication("StatelessAPI") {
    case (key, secret, _) => true
  }
  auth.credentials(req) match {
    case Full((k, s)) => count(By(key, k), By(secret, s)) > 0
    case _ => false
  }
}
val httpBasic: PartialFunction[Req, Unit] = {
  case req if reqPasses(req) => 
}

/*
 * In Boot.scala
 */
// stateless api -- no session created
LiftRules.statelessDispatchTable.append(Client.httpBasic guard StatelessAPI)

The key thing to realize is that the PartialFunction used to guard the API takes, as you’d hope, a Req. It took me a while to figure this out, as both Tim’s and David’s examples don’t use the value passed to the PartialFunction. Of course now I see that it’s right there in the PartialFunction’s type signature, so there you go for my great Scala knowledge!

If you’re not on the Lift mailing list you might not know that I am organizing a little meetup this Wednesday January 26 at 19:00 at Café Kobalt here in Amsterdam. If you’re interested in Lift, Scala, or just web frameworks in general, come on by!

Because I love making stupid little libraries I’m proud to present CAP, “CAP is an experiment is stateful PHP form handling.”

As you can see, closures are bound to form elements. Pretty cool, no? PHP 5.3+ only.

I gave an introductory presentation on Lift last night at DuSE VI. You can download the pretty PDF or view in on Slideshare. And guess what, it’s already out of date: 2.0 is now out!

On my Slicehost virtual server (signup with my referral link) I originally set up Apache as my web server, with a bunch of virtual hosts to manage serve different domains. This has worked well but I am now working on projects (namely Lift apps running in Jetty) where Nginx is a much better solution. So, I decided to stick Nginx in front of Apache.

Translating my vhosts was quite easy: I simply changed their Apache settings to only listen on localhost:8888 and created settings in Nginx that look like this:

server {
  listen 80;
  server_name thedomain.com www.thedomain.com;
    location / {
      access_log off;
      proxy_pass http://127.0.0.1:8888;
      proxy_redirect off;

      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

However, I also want to occasionally throw up the odd PHP script for testing. There’s no mod_php (or libphp, or whatever it’s called these days) for Nginx and the most common solution is using FastCGI. That looks good but I figure that since I already have Apache playing nicely with PHP, I might as well use it. So how to do it? I set up the following in Nginx:

server {
       listen 8989;
       server_name BubbleFoundry.local;
       location / {
                 proxy_pass  http://127.0.0.1:8889;
                 proxy_redirect off;
                 proxy_set_header X-Real-IP $remote_addr;
                 proxy_set_header Host $host;
                 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       }
}

And in Apache I simply had my default virtual host listen on 8889.

This works well, though I noticed that when Apache returns a 404 error the response returns back to Nginx. If I go to http://myserver:8989/somefolder, it gets kicked back to Nginx which then returns a 404 error. http://myserver:8989/somefolder/ (notice the trailing slash), on the other hand, works. Probably just need to tweak something in my Apache settings, but it’s good enough for now.

This post will probably only be useful for people developing using Scala and the Lift framework so, my other readers, consider yourself warned!

Read more »

I’m really liking Scala and its premiere web framework, Lift, so if you’re interested in building web apps in a language that mixes functional and object-oriented paradigms well and does cool concurrency stuff, check them out.

As I’ve been really getting into Javascript this year, I’ve been seeing a lot of parallels between Scala’s functional features and the surprising amount of functional things you can do in Javascript as I learn Scala. My hope is to eventually supplement to the many excellent Scala tutorials for programmers coming from Java or Ruby with one geared towards Javascript programmers.

In the mean time, I’ve made porting Scala’s case classes to Javascript the first test of my ability to draw connections between the two languages. I’ve just started and you can follow the progress of caseclass.js on GitHub.