Lars Trieloff's Collaboration Weblog

I had a short e-mail exchange with Peter Svenson yesterday, who has some really interesting ideas on web development, Javascript and frameworks and wanted to introduce Sling to him. Unfortunately the Sling website is a bit terse on "big picture" introductions, so I though I share my introduction with my blog readers.

What is Sling? This is a fairly complex issue, because Sling combines many aspects. The main idea is that Sling is a web framework that uses a JCR container such as Apache Jackrabbit as repository. The interesting part here is JCR, which is a storage API that allows you to store nodes which can have child nodes and properties, so the best way is to imagine a JCR repository as a giant storage tree or as a file system on stereoids, as it supports typing, transactions, versioning, full-text-search, oberservation and so on. The main role of Sling is being a translator between the storage repository and the client application and this means representing the Nodes in the JCR tree (that have a path) as Resources (as in REST) that have a URI. ;:A resource can have different representations, for instance a blog can have the HTML representation (blog.html) and the Atom feed representation (blog.atom). Representations are not limited to the resource type, there could be another HTML representation, for example the archive page (blog.archive.html). Representations of a resource are generated on GET requests and there are two high-level ways to do it: Servlets (the classical, heavy-weight Java way) or Scripts and Templates. Among the script engines currently supported are Rhino (Javascript), Ruby, Velocity and Freemarker. Basically, there is a script file or servlet for each representation (in our example html.js, html.archive.js and atom.js could be imaginable). If you want to create a new resource type, e.g. blog entry, you just have to create a new folder and put the appropriately named scripts into this folder. Secondly, a resource can have different behaviors. Again, behaviours are implemented either via Servlets or Scripts. The default behavior is to create a node when posting content to a collection, replacing a node when sending a PUT to a resource and deleting a node when sending a DELETE request. You are, however able to override this default behavior by placing scripts into the right folder. These scripts could for instance validate comment contents before creating the node. This is basically where server side scripting comes into play.

Microjax is based on a clever default handling of certain requests. This means representing resources as JSON objects on GET request and processing JSON request entities for PUT and POST. Additionally, Sling and Microjax introduce two Javascript-based templating mechanisms. Sling comes with the built-in ESP, server-side templating mechanism that will allow you to mash up HTML with embedded Javascript that will be executed server-side, e.g.

<ul>
<% foreach (child in node.children) {
 %><a href="${child.path}"><%= child.properties.name %></a><%
} %>
</ul>

Microsling extends this pattern by introducing EST, which allows you to write the same script, which will then be transformed by the server into a proper Javascript with lots of document.write(...) expressions that can be executed on the client-side.

To sum it up: Take a look at Sling, it is an interesting way to build content-centric applications.