From time to time someone will come to the Lift mailing list asking how to debug their applications from an IDE. I have to confess that most of the time I simply use println or write a spec2 test.

But today I decided to just go ahead and write a little intro on how to setup sbt and intelliJ IDEA 11 to debug a Lift application (and for that matter, debug any application running from sbt.

You can find the article on the Lift wiki 

Feel free to edit the wiki if you find any mistakes or leave a comment here.

Enjoy

  Diego

Lift has an amazing component to write applications like surveys, it is called wizard. And you can find more information on the Simply Lift book.

One limitation it has, is that you cannot place the fields on any part of the page. They all appear one under the other. There is some work being done by Peter Brant which I really hope makes it into 2.5.

But for those who are a bit impatient or want full control about everything, I think this post will help you.

The sample application that I wrote shows you how you can use RequestVar's and values to pass information from one page to the next one. The core of this technique, is to assign the value from an input field to a val, and use S.redirectTo() to assign the val to a RequestVar. This step allows you to have the values from the previous page on the current page.

On the second page, you need to assign the value of the RequestVar to a val, so that it will be available on the S.redirectTo() call to the third page.

You then pretty much duplicate the same idea across all pages.

This example project includes a back button on each form and it also support the browser back button.

Call Scala code from JavaScript.

This is a question that has been coming up on the mailing list more and more often. The usual answer is to use jsonCall or ajaxCall (and soon we will have ljsonCall, but there will be a full post just for that :) )

There is one other method to use that may fit your needs. It is ajaxInvoke(). I had kind of a hard time trying to see how to use it best, but just the other day Torsten Uhlmann posted a great example on the Lift mailing list that made a huge difference for me.

You can see here how I use it to log a phrase on the server, and then I open a JavaScript alert box and after that I hide the “Finish” button. All by clicking on the Finish button.

Drawbacks.

One thing I don't like about this technique is that if you have 10 form fields, you will need 10 RequestsVar’s and 10 val's. I'm planning on trying different ways to solve this.

One way I'm thinking is by using actors (I know, it sounds kind of odd, but I like coming up with odd solutions sometimes). The other option is to use the snapshot/ restore capabilities of RequestVars.

But in the meantime, you have something to work with.

Code.

You can find the full source code on github.

Demo.

Thanks to David for hosting my demos and Derek for setting up the server for me, you can access it here.

Feedback.

I'm happy to hear any feedback you may have, so feel free to email me on the Lift mailing list.

Enjoy

  --Diego

I wrote in the past about having different comet actors on the same window but on different tabs. This in a use case that I run into pretty often. And as I was getting tired of copying and pasting the same files over and over, I decided to write a little library to do just that, allow you to have different actors per browser tab without having to worry about dispatchers, etc.

Sample application

Imagine you are running a site like ebay, your users are watching two different auctions on two different tabs. You could simply have one comet actor handling the load and choosing when to update each tab, or you could have one comet per auction. I prefer the second option.

In this example application, the page that displays the auction includes a comet actor whose name is the auction id. You can choose anything you want.

I use the name of the actor in two places. As the key for the Map of actor names -> dispatchers, and once there is an update for any of the auction items, I can lookup the dispatcher that needs to send a message to the comet actor(s) to update the browser tab.

I had explained how all these works in detail on a previous blog, but on that code there was a bug where dead actors, those that have not been on a page for a while, would stay on the map of names -> dispatchers. On this new version, I use the localShutdown method to unregister the comet actor right before it is shutdown by Lift.

How can I use it?

In most cases you would only directly use three classes/traits. You would extend the trait InsertNamedComet. All you do here is override two lazy vals,

If you do not override the lazy val name, each time a user loads your page, a new comet actor will be created, here you can set the name to be the value stored on a RequestVar, SessionVar, a S.param(), etc.

Then you include a tag on your html files to call this class, for example, if your class is class PutCometOnPage extends InsertNamedComet, on your html you would add:

The other trait you would extend is NamedCometActor. This trait already extends CometActor and all you have to do is override one of the message handlers (lowPriority, mediumPriority or highPriority) and define the render method.

The NamedCometActor trait implements localSetup and localShutdown to register and un-register the comet actor from the dispatcher.

To send a message to the correct comet actor you use the method CometListerner.listenerFor(Full(name)). This snippet shows you one way of sending a message to our comet actor:

And that’s all. The library will take care of only sending updates to the actors that need the information.

Code and Demo?

As always, thanks to David P. and Derek for hosting my sample applications, you can access this demo here. Click on any of the two links for "First item" or "Second item". Then open a new tab for either the same item or a different one. Clicking on "Bid" will increase the price and if you are looking at the same item on another tab or totally different browser (different sessions) the price will update everywhere.

You can access the source code of the library on github and the source of the demo application is also on github.

Enjoy

  Diego

Just the other night I watched this very easy to follow presentation on scalaz by Nick Partridge.While I was watching it, I kept wondering how I could apply any of it on my Lift application.

But before long, I saw the method ~ (which in scalaz’s source code is written as unary_~ ). What it does is pretty straight forward, you pass in an Option as its argument, it will get the value from inside, and if you have Nothing, it will return the zero value for the type.

An example may be better to explain this:

I think it is pretty neat, and while it may seem overkill to include a whole library into your project just for this, I am planning on using more of what scalaz has to offer. This is just one small step in that direction.

So The next day I went to my laptop and rushed to use the new trick I learned. But before long scalac reminded me that in Lift, we use Box[T], instead of Option[T]. I scratched my head for a little bit trying to see how to address this and I settled on rewriting the ~ method to take a Box instead of an Option.

I went ahead and cloned the scalaz repo and grep to the rescue to find where ~ was defined. I looked at the OptionW.scala file and after reading it, I changed my mind and decided to just copy/paste/edit the whole file into my project.

The result is this:

Was it worth the trouble?

I think so, on one of my classes I had several lines similar to this:

I think it is easier to read, the only think I’m a little worried about is that if another developer sees this, and is not familiar with scalaz, they may have a hard time finding out where that ~ method comes from, because I don’t want to have to add a comment on every single class I use this method. I guess I could just rename the method to something else, but for now, I’m the only one reading my code.

That’s all for today.

Thanks

  /Diego

On my quest for the ultimate bookmark and back button support for comet and ajax based lift applications, I decided to ask on the Lift mailing list how you could call Scala code from the browser. I really thought that it was going to be pretty hard to understand. But to my surprise, it was very easy.

There are at least three methods, ajaxCall, ajaxInvoke and jsonCall (all in the SHtml object). This time I'm using jsonCall.

Why do I need this?

Because when you visit a link that has been bookmarked or shared by email, etc, I needed a way to execute some Scala code that would update the UI based on the values on the URL after the # hashtag (this is the fragment of the URL.)

I initially used ajaxCall to achieve this, but I had to send two parameter to Scala, one was the name of my comet actor, and the other was the value after the hashtag.

The signatures of ajaxCall are:

As you can see, there is only one JsExp variable you can pass, so I decided to concatenate the two values using a pipe ( | ), and then used the split() method to parse the input on my Scala code.

Needless to say this didn’t look nice at all. Luckily David had posted before that he prefers to use jsonCall. I had to read the signature of it a few times to see how it was any better than ajaxCall. And all of the sudden it clicked. the JsExp could be raw json data.

So off I went and refactored my code to use it. To my surprise, I kept getting a compiler error, which I just had no idea how to fix :(.

The compiler was telling me:

The solution? Add SHtml. before jsoncall

Using jsonCall works almost perfectly, the Scala method that is called by jsonCall gets a parameter of type Any, but underneath it is a Map[String, Any]. This is my current work around:

Not the best thing but it gets the job done, if you have any better idea, please let me know. David did asked me to enter a ticket to add a jsonCall version that would return a JValue, which you can then work with using lift-json.

What happened to the rest api?

If you read my previous blog post you would have noticed that I used a REST API because I needed a way to execute Scala code triggered by the browser. jsonCall does this in a much cleaner way, so out with the REST code.

How does it work?

On my sample application I have 3 links, each of them is associated with a jsonCall method that passes the name of our comet actor and the value of our href. We use this value to do a look up by key to get the name of a city and state.

We then send the result of the look up to our comet actor which will update our browser screen.

When we click on any of the links, we also update our url by adding a value after the hashtag. This is part of adding support for bookmarks and back button.

So the url goes from looking like: 

http://dmedina.scala-tools.org/2/liftactorform2 to 

http://dmedina.scala-tools.org/2/liftactorform2#bbq1=2

Bookmark and back button magic.

When you load a page that has a value after the hashtag, there is JavaScript that gets executed. This JavaScript extracts our comet name as well as the fragment from the url and executes the jsonCall that correspond to the correct link you would click to get the same city and state. This is kind of to save some effor, but is something that I may change in future versions, because I think it is pretty fragile.

From this point on, it is the same as if you clicked on a link.

Final thoughts.

On the live demo, there is a lot of JavaScript that was manually added to the default.html template. Take a look at that file if there are things that don’t quite make sense, and of course, leave a comment or email the mailing list if you have any questions.

I have plans to improve on this example, but I think that this is a good proof of concept that you do not have to say goodbye to sharing links or other things we are used to on the web just because you have some ajax calls on your application.

Code Sample?

Sure, you can find a working demo here (thanks to David and Derek for hosting all my sample applications) and the source code is on github

Enjoy

  Diego

One of the first, if not the first question, that I asked on the mailing list was if Lift had support for browser history when doing ajax requests.

I was coming from using GWT, and they had a nice mechanism for doing this. It uses the url fragment identifier to achieve this.

I had a few answers to my question, but I was too new to Scala and Lift to really implement anything.
I kept thinking about how to do this in the back of my mind. I wanted to write an application that would use ajax or comet to update parts of the UI, so no full page refresh would be done. And I also wanted to be able to share links with other users, and once they click on it, it had to take them to the same page, with the same content I had on my browser.

After much thinking, and reading this answer (I can't find the thread any more) from dpp, I finally got it working!

You can see it in action on this demo site

What does it do?

Before you click on any of the 1 2 3 links, look at the url, it looks like http://dmedina.scala-tools.org/2/liftactorform.

When you click on the 1 link, jQuery sends a PUT request to a REST interface running on the same server.

This PUT request has two pieces of information, it has the value 1, which just represents the link name, and it also has the name of the comet actor that is present on this page.

Once the REST API receives this request, it parses the json data and it looks up a city-> state pair based on the id we sent (for sake of simplicity, I did not include a mapper class).

After locating the city and state that match our id, it sends a message to the comet actor we have on our page and tells it to update the UI with the city and state.

What about the back button?

Now, look at the url, if you clicked on the 1 link, the url will now have a fragment, it has #bbq1=1. You can now go ahead and click on the other links. You will notice that the url fragment changes, the city and state change, but there is no full page refresh.

You can click on the back button on your browser and the city and state values will update accordingly. You can even have multiple tabs open simultaneous and each of them will have its own city and state. I’m able to achieve this by using different comet actors on each tab.

Final thoughts.

In my case, this sample application opens up a lot of possibilities, I know there may be other ways of implementing the back button / bookmark feature, like the one outline here, but I’m pretty happy with using a REST API and jQuery. Oh, and I’m using the BBQ jQuery plugin to do the hashtag magic.

Where is the code?

As always, you can find the complete code on github and thanks to David and Derek for providing the server that is hosting the demo application.

Enjoy

  Diego

A few weeks ago I saw a question on the mailing list that got my attention. It made me think of some of the great things you could do with Lift and its LiftActors.

In this blog post I’ll show you how after a user submits a form, you can start an asynchronous process, and once it finishes, Lift can notify the user of such event.

What I find great about this approach, is that the user can move on and do other things on your site while your server is doing some time consuming processing of data. This approach is much more friendly than making the user wait several seconds or even longer until the confirmation page loads.

How does it work?

When the page loads, the snippet PlaceCometOnPage is called. This snippet is in charged of setting the name of the comet actor that will notify the user once the background process finishes. It uses the sendCometActorMessage method, which sends a message to a comet actor, but if the actor is not initialized, it will start it and send the message to it, pretty handy method.

We store the name of our comet actor on a RequestVar. This allows us to pass the name to other snippets on the page. Remember that a Request in Lift is the original page load and all the ajax calls your page generates.

In our case, the other snippet that needs access to the name of the CometActor is a form on the page, on this form you can select the name of a state and city. Once you submit this form, a message is sent to a lift actor. (This message has the name of the CometActor as one variable.)

Here we start two processes (not OS process, but a branch or fork of tasks if you wish).

On one hand, the form returns control to the user’s browser, so she can either visit some other page, or wait for the notification that the long running process is done.

On the other hand, we have a LiftActor doing some background process based on what was submitted on the form. On the example application I’m attaching, I simply use Thread.sleep(), but in real life you could be fetching data from some web service, you could be processing a large image or video, etc.

Once the LiftActor finishes his process, it sends a message to an object MyListeners, which is in charge of returning the Actor Dispatcher that knows which comet actor is the one that needs to update the user’s browser.

Then the DispatcherActor actor sends the resulting message to the comet actor that is on the page, waiting to update the user’s browser.

Finally, once the CometActor gets the DoneMessage message, it goes and notifies the user that the long running task has finished. On this blog post I explain in more details the use of an Actor Dispatcher.

Small gem.

A trick that David (@dpp) showed on the mailing list was how to make RequestVars available after a full page reload. You see, Lift offers SessionVars, RequestVars and WizardVars (I think there aren’t any other). What I wanted was a “TabVar”. which is like a SessionVar (to maintain the value after a page reload (which happens once you submit a form), but I wanted them to be independent from the other browser tabs).

The way around this is using RequestVars, with a snapshot() method. Basically, you take a snapshot of some RequestVars, and once the page is loaded again, you can restore those values. I am using this technique on the sample application I used to write this blog post and it works great.

David was also kind enough to indicate that 2.4-SNAPSHOT has a simpler way to achieve this. You could instead use:  

Where is the code?

As always, you can find the source code for this sample application on github at:

https://github.com/fmpwizard/lift-conditional-drop-down-menus

If you are running this application, select the “Liftactor Form” menu from the left.

Live Demo.

Thanks to David Pollak and Derek Chen-Becker, I now have access to a server to host live demos of the Lift applications I write about.

You can access this sample application at http://dmedina.scala-tools.org/1/liftactorform . I’m hoping this will help you better understand what I’m talking about here :)

I want to give a big thanks to both David and Derek for providing this server and setting it all up.

Final thoughts.

I’m personally very happy to be working with Scala, Lift and actors. In the past, while I was working with PHP, to achieve something along the lines of what I describe here, I had to resort to adding one more component to the stack, Gearman, while gearman is a great tool, it can sometimes be overkill for some simple tasks.

Oh, and if you want, you could use Akka actors to do the background tasks, I may write about that variation in the near future.

Update.

Derek Chen-Becker wrote a blog post where he integrates Akka with Lift and Lift's Comet Actors, it's a very good description of how to integrate them together.

If you have any comments, questions, please feel free to leave them here or email me at diego@fmpwizard.com.

Thanks and enjoy!

  Diego

I really thought that after my last post, I was going to be able to implement conditional drop down menus on my current application.

But as I started implementing it, I realized that the examples I worked on had two drop down menus depend on just one other list. What I needed was a “cascade” effect.

You needed what?

Let’s say that you are adding a product to your database, you select a category, this filters the sub category list, and once you make a selection on the subcategory list, a third list, a sub subcategory is updated.

I tried implementing this using Wiring but I could not find a way to get the 3rd drop down menu to update its value.

This is when I turned to nafg and his Reactive Web project. He quickly reply with some code that was supposed to do what I needed. And it almost worked, there were a few emails back and forth, and after I explained in detailed what I needed, he make the necessary changes to reactive web and I now have a working example.

It turned out to be pretty easy to do, and the code is easy to follow.

Explaining the code.

The complete class is this:

And here I'll step through the code explaining what each line does.

You first define the main drop down menu using:

val statesSelect= Select(Val(CitiesAndStates3.states))

CitiesAndStates3.states simply returns a list of States for our main drop down menu.

We set the default/selected item like this:

statesSelect.selectedIndex.value ()= Some(0)

After adding this line of code, once you load the page http://127.0.0.1:8080/reactive, the States drop down menu will display the first state from the list as the default value.

You then set the Signal that will trigger a change on the second menu like this:

val validCitiesSignal= statesSelect.selectedItem map {
   case None => Nil
   case Some(state) => CitiesAndStates3.citiesFor(state)}

You are basically telling reactive web what is the relationship between the cities and the states. The method CitiesAndStates3.citiesFor(state) generates a list of cities that belong to state. This method could be a call to your database to retrieve all the cities. We use a List[String] to keep this blog post simple and focused.

We then add the drop down menu for the cities, here the argument for Select() is the Signal we previously defined. And we also set the default selected item for the cities drop down menu.

val citiesSelect=Select(validCitiesSignal)
citiesSelect.selectedIndex.value()=Some(0)

Scala allows you to define the Signal in a few different ways, this is another way to create a Signal:

val validIdsSignal = citiesSelect.selectedItem.map(_.toList flatMap CitiesAndStates3.idsFor)

The idea of this line is the same as when we defined validCitiesSignal, once there is a change on the selected city, we call the method CitiesAndStates3.idsFor (the city is implicitly passed here), to get a list of IDs that belong to the selected city.

Once we have our validIdsSignal, we use it to create our IDs menu and we again tell reactive web to select the first element of the list (on the example application I posted, you only get one id per city, but you can of course have many ids per city).

val idsSelect=Select(validIdsSignal)
idsSelect.selectedIndex.value()=Some(0)

And finally you bind some html to the select objects you just created using CSS Selectors

def render ={
   "#states" #> statesSelect &
   "#cities" #> citiesSelect &
   "#ids" #> idsSelect  }

Pretty simple :)

Where is the code?

You can find a working example application on github. To run it you can:

0- You will need http://code.google.com/p/simple-build-tool/ Simple Build Tool installed.
 1- git clone git://github.com/fmpwizard/reactiveweb.git
 2- cd reactiveweb
 3- sbt update
 4- sbt ~jetty-run
 5- Go to http://127.0.0.1:8080/reactive and select different cities and/or states and see the magic unfold :)

Final thoughts.

While I wasn't able to get Wiring to do what I wanted, I'm sure that it will not be long before this and other use cases are covered by Wiring. But until then, you can use Reactive Web ... and one of the best things is that you can use Reactive Web on one page, and Wiring on another. Well, you can even use them on the same page or snippet, (I haven't tried using them on the same snippet, but I take nafg's word for it :) ).

I personally find the logic behind reactive web easier to understand than how Wiring works. I like how you define a Signal, then a menu that is based on that Signal, and you just keep doing things this way.

I know there is a lot more you can do than drop down menus and I look forward to using other features of Reactive.

On my last article I meant to compare two ways of doing conditional drop down menus using Lift. I wanted to compare using simple Ajax and wiring. But I ended up doing both cases using Ajax :( (This is because Lift makes is so easy :P).

But I still wanted to use Wiring, and be able to write about it. Last night A few nights ago, I was able to update the sample application with a third example, this one really uses wiring!

What I'm showing here is how wiring can be used to filter two drop down menus based on the selection made on a third menu.

What does it do?

You select a state from one drop down menu, and the list of cities is filtered only showing the cities that belong to the state you just selected. Another drop down menu is also updated, which shows you a number, this number only belongs to the selected state.

I know this last field could have been a text field, but I wanted to show drop down menus, because there are several wiring examples out there showing how to use text fields already :)

How does it work?

I define the menu with the list of states to be a value cell, this is our starting point.

Then we define the other two menus to depend on changes to the state menu. You do this by using the lift method. I'm sure there is a better way to express the relationship than using val cities= selectedState.lift(_ + ""), if I find a better way, I'll update this post.

Then, you define the method that will render the drop down menus on the browser. Here you can select some effects that can take place before the lists are updated.

I'm not sure this is the best way to create the dependant menus, because I'm storing the complete html in each val, but it does the job for now.

Where is the code?

I posted a complete application on github, feel free to leave a comment and I hope this post helps people understand wiring better.

Enjoy,

  Diego

Update:

It turned out that I got a bit sidetracked as I was trying to get this example working, and I did not end up using Wiring. What I refer to as Wiring on this post is actually just Lift’s easy way of doing Ajax (so I compare Ajax with Ajax here :( ). But don’t worry, I still want to use Wiring, so I’ll find time this week to update the sample project and I’ll post again.

Thanks.

The Post

I have been meaning to try Wiring on any of my Scala projects for some time now, but the right use case was not presenting itself. That was until last week, when I needed to have a few conditional drop down menus.

What I needed was an option to select a value from one menu, this menu had a few sub-menus, and once you made a selection on that second drop down, a group of 10 different drop down menus had to have their values filtered.

I remember seeing an example on the lift site that had two drop down menus, so I decided to modify that example and see how it would work for me.

The moment of light.

As I was renaming some methods, changing some values on the select elements, I realized that wiring should be able to do the same, but in a simpler way. And I started coding around Wiring.

At first, I just took the example about creating an invoice using Wiring and tried to replace the Tax Rate field by a drop down menu. What I was hoping to achieve was that the example would work as it does on the live demo. And after correcting some mistakes I made along the way, I got it to work. This was pretty exciting, it meant I could use Wiring on this project!

I stopped there and I put together this example project on github, which shows both, the Ajax and the Wiring way of doing the same thing. Now you can compare and decide which one you prefer.

Comparing the code.

The Ajax partion looks like this:

and the Wiring looks like this:

It is very possible that I overlooked something on the wiring example, after all, this is the first time I get a chance to work with it, so feel free to tell me if I should do anything different.

Thanks

  Diego