Check out the Tutorials section.

Today I want to write a little about Lift Framework. It is a web application framework targeting Java web application containers written in Scala programming language. Scala is gaining popularity and according to various language popularity ratings (TIOBE and Transparent Language Popularity Index) it is rising in popularity and at the time of writing popularity index is over 0.23% in both metrics. It is a good result considering how much attention programming languages are getting in general. So considering this it seems natural that someone would write a web framework based on Scala. Especially taking into account that Scala is often called “static dynamic language” and even compared to the likes of Ruby. The later got much attention when the famous Ruby on Rails framework was released. Can it be the case that Lift will mean the same for Scala? Might be. Twitter has moved from Ruby to Scala, Foursquare have ported their application to Lift Framework and new Novell Vibe solution was all written using Lift.

What I like about Lift?

View-centric approach. The concept is somewhat similar to JavaServer Faces, where you have a view and reference components and beans from that view. That allows you to compose complex views and keep their logic separate (in case of MVC your controller will be a hub to all the services and data you are passing to the view, so to add any new element to the view you need to update the controller to fetch the data and update the view to make use of it). But in Lift things are a bit different. The view is a simple HTML template, that can access snippets (snippet is a peace of code that can generate content, like a component).

For example lets define a view:

<div class="left:My.text"></div>

Now we need a snippet:

class My {
  def text = "*" #> (<b>Some text</b>)
}

He we tell “replace all content with Some text“. We define a CSS selector “*“ and then fill the matching element with the markup. Since Scala natively supports XML, we can pass the XML content with no special markup. So, you may ask “If the markup is complex I am suppose to write it all in my snippet?”. And my answer is “not at all”. By using CSS selectors you can enter values in specific places. For example we have a view:

<div class="lift:My.complex"><span id="text"></span><b id="boldy"></b></div>

Lets fill span and b with some text.

def complex = "#text *" #> "Normal text" & "#boldy *" #> "Bold text"

And of course you can iterate and repeat the content, build tables and so on. This approach is especially convenient for ajax requests.

Ajax and Comet support. Lift allows you to create ajax actions and update content on the page with 0 JavaScript. It does this with the help of helper methods that generate markup and JavaScript for invoking AJAX calls and of updating the page. You can also pass your own JavaScript that gets executed after an ajax request. And by supporting Comet, Lift allows server to push the changes to the client when required.

Scoped variables. That is a functionality that is similar to using Spring AOP scoped proxy. In Spring you define a bean, set scope to session or request and inject to your controller. In Lift you define a property of type RequestVar or SessionVar to hold the value. For example sessionVariable is session scoped:

class My {
  object sessionVariable extends SessionVar[Box[String]](Empty)
}

Box here is a value holder that can be empty or contain a value, in our case - String. Lift makes use of Java Servlet technology and session scoped variables live in application session. And ofcourse you can have fully stateless application as Lift has no additional state.

Lift also comes with two persistence solutions a Mapper ORM and a broader solution (Record) that also supports document stores, like CouchDB and MongoDB.

You can see some more examples at Lift demo page.

Conclusion

If you’re looking for the next web application framework, Lift is definitely worth looking into. It is fast, backed by functional programming language (which gives nice things like mixins (Scala calls them traits), function objects), actively developed. And fairly documented - has two free books, wiki and some blogs about it. I say fairly, because in this respect there is certainly room for improvement.

Yesterday I was facing a problem of exporting JGraph graph to a SVG format image. Neither SVGGraphWriter, neither a solution presented in JGraph tutorial didn’t work.

Using SVGGraphWriter from JGraph I got all of my graph nodes and connections just dumped one on the other. JGraph manual (can be found here, page 97) proposes using Apache Batik and painting the graph using SVGGraphics2D provided by the library. The problem is that

JGraph graph = ...
SVGGraphics2D graphics = ...
...
graph.paint(graphics);

just doesn’t work. So I decided to explore JGraph source and see if there is any way I can make this work.

And voila few minutes and I found a solution:

OutputStreamWriter writer = ...;

Object[] cells = graph.getRoots();
Rectangle2D bounds = graph.toScreen(graph.getCellBounds(cells));</code>

DOMImplementation domImpl = GenericDOMImplementation.getDOMImplementation();
Document document = domImpl.createDocument(null, "svg", null);

SVGGraphics2D svgGraphics = new SVGGraphics2D(document);

svgGraphics.setSVGCanvasSize(new Dimension((int)Math.round(bounds.getWidth()), (int)Math.round(bounds.getHeight())));

RepaintManager repaintManager = RepaintManager.currentManager(graph);
repaintManager.setDoubleBufferingEnabled(false);

BasicGraphUI gui = (BasicGraphUI) graph.getUI(); // The magic is those two lines
gui.drawGraph(svgGraphics, bounds);

svgGraphics.stream(writer, false);

Aspect oriented programming is by no doubt a powerful tool when used correctly. However, it can lead to problems when using, what I call - ninja aspects.

Ninja aspects are aspects, that are there in the code base waiting to strike without a programmer even knowing it.

A popular way to use transactions with Spring is by using its @Transactional annotation. Annotation tells a programmer, that annotated method (or all class methods if annotation is at a class level) should be decorated with transaction handling code. Annotation is a very visible way of saying “an advice is applied here”.

class Test {
    @Transactional
    public void transactionalMethod() {
        // ...
    }
}

Lets take the same example and apply a ninja aspect.

<bean id="test" class="Test"/>

<tx:advice id="txAdvice" transaction-manager="txManager">
 <tx:attributes>
  <tx:method name="transactionalMethod"/>
 </tx:attributes>
</tx:advice>

<aop:config>
 <aop:pointcut id="testPointcut" expression="execution(* Test.*(..))"/>
 <aop:advisor advice-ref="txAdvice" pointcut-ref="testPointcut"/>
</aop:config>

Now, we don’t need the annotation and transaction handling advice is still applied. This makes the programmer looking to the class Test unaware of such behavior. It is possible that the mentioned programmer changes the body of the method in the way, that it does not require transactions (for example, instead of taking information from the database it now uses a web service), but he is not aware, so transaction handling stays. If the aspect is transactions, we just loose some performance (potentially even call the database to commit the empty transaction), but aspects might be more serious than that. They can lead to unexpected (from the unsuspecting programmers point of view) behavior and make the code harder to understand. Of course, we will deduct from the stack trace, that the class is decorated with an AOP proxy, however that leaves us with the challenge to actually locating the advice.

It is very important to make all aspects visible, otherwise they can strike from the shadows and leave an unsuspecting programmer wondering, what the hell happened…