When you look at the technology options one has for a CMS authoring interface there are two big camps: the web UI and the fat client (be it a Java client, .net or similar). The relative pros and cons of these two technology choices are usually described along these lines

• web clients are easy to deploy whereas fat clients are not
• on the other hand, fat clients provide a richer user experience and better usability overall.
  

Consequently, fat clients are often suggested as the preferable solution for so-called power users whereas web clients are supposed to be the right thing for occasional CMS users.

Well, these considerations have been around in the CMS community for about 10 years and I have not seen a lot of discussion about them. But I think they are not true anymore. The world has moved on and browser-based user interfaces have not only caught up with fat clients in terms of usability - I think they are even about to provide a better user experience.

This is part of a very large trend in the computer industry: applications that were once desktop-based move into the browser with the primary examples being GMail or Google Docs. This trend has been facilitated by vast increases in browser performance and better widget libraries like JQuery or Ext. These improvements have made it technically possible to implement user interfaces that are as rich as desktop applications.  Drag-and-drop, tree widgets, responsiveness of the UI - most of what was once thought to be the desktop app's advantage now also exists in the browser.

However, there is more to this trend: I, for example, have grown completely accustomed to having all my productivity apps within the browser. And because I spend most of my time within the browser it is the browser's infrastructure that defines "convenient" for me, be it password management, download- and upload-behaviour, the browser extensions I have come to rely upon or simply the fact the the browser is always running anyway.

In my case the increasing tendency to use browser-based apps rather than desktop-based ones even goes out to the choice of my IDE for component development (arguably the most power-user-y thing to do). Day offers the Eclipse-based CRXDE as well as the browser-based CRXDELite and I find myself starting to the latter more and more often - because it is often simply more convenient.

So, coming back to CMS authoring interfaces: In my opinion the fat client's deployment hassles are not compensated by usability anymore. Maybe, it is time for the CMS community to revisit this topic.

Congratulation to the ModeShape team who have just released version 1.0:

I’m very happy to announce that ModeShape 1.0.0.Final is now available. With this release, ModeShape now implements all JCR Level 1 and Level 2 features and the optional locking and observation features! And as with our 1.0.0.Beta1 release, ModeShape supports querying repository content using the JCR-SQL2 query language defined by the JSR-283 specification.

It is great to see this project advance so quickly as it stepped onto the scene only 2 years ago (at that time the project was called JBoss DNA).

ModeShape implements a couple of interesting concepts. In particular, I like the idea to make accessible various siloed repositories through a unified interface (JCR) which is similar to Day's ContentBus (the repository architecture that previous versions of CQ were based on) or the CRX Connectors.

It is great to have multiple open-source JCR implementations (others are e.g. Apache Jackrabbit or eXo) that compete against each other in terms of features or performance (or have different licenses).

In Apache Sling the JCR nodes usually determine the URLs of a Sling-based web app (and consequently for CRX or CQ5-based apps). For example, Sling will look for the resource http://www.example.com/content/a/b at the path /content/a/b in Sling's JCR repository. This 1-1 mapping is often useful, but there are valid use cases for alternative/additional mappings, for example a web site migration from a legacy site onto Sling.

In simple scenarios Sling's vanity url mechanism can be used: adding a property "sling:vanityUrl" with value, say, "/old/legacy/path" will render the node for the legacy URLs as well. sling:vanityUrl is a multi-valued property, so an arbitrary number of legacy URLs can be specified. As the property's name implies it is also helpful for mapping short URLs (that can easily be communicated) to nodes that are potentially deep down a content hierarchy.

In more complex scenarios one can resort to Sling servlets. These are servlets deployed into Sling's as OSGi bundles. Obviously, inside of a servlet any arbitrarily complex business logic can be implemented (e.g. for mapping legacy URLs to new ones). The URLs that a servlet shall respond to can be specified through annotations.

An easy way to create such a servlet is by using CRXDElite, the web-based IDE that ships with CQ5.3. Here's how to do it:

• Fire up your browser and point it to /crxde at your CQ5.3 installation
• Create a folder "myapp" in /apps
• Create a new OSGi bundle and add a servlet
  

Here is the scaffolding code for the servlet implementation that extends the convenience class SlingAllMethodsServlet:

package com.day.dev.servlets;



import java.io.IOException;

import javax.servlet.ServletException;

import org.apache.sling.api.SlingHttpServletRequest;

import org.apache.sling.api.SlingHttpServletResponse;

import org.apache.sling.api.servlets.SlingAllMethodsServlet;

/** * @scr.service interface="javax.servlet.Servlet"

 * @scr.component immediate="true" metatype="no"

 * @scr.property name="service.description" value="my servlet"

 * @scr.property name="service.vendor" value="Day"

 */

@SuppressWarnings("serial")

public class MySlingAllMethodsServlet extends SlingAllMethodsServlet {



    @Override

    protected void doGet(SlingHttpServletRequest request,

            SlingHttpServletResponse response) throws ServletException,

            IOException {

        // do something

    }



    @Override

    protected void doPost(SlingHttpServletRequest request,

            SlingHttpServletResponse response) throws ServletException,

            IOException {

        // do something

    }

}

• Finally, deploy the servlet by executing Tools > Build bundle. Your new bundle should now show up in the OSGi console at /system/console/bundles
  

An important aspect are the annotations that determine for which URLs Sling will invoke the servlet. The most important annotations in this context are:

• sling.servlet.extensions: The URL extensions supported by the servlet for GET requests
  e.g.:
  @scr.property name="sling.servlet.extensions" values.0 = "TEST_EXT_1" values.1 = "TEST_EXT_2"
  
• sling.servlet.methods: The request methods supported by the servlet
  e.g.:
  @scr.property name="sling.servlet.methods" values.0="GET" values.1="POST"
  
• sling.servlet.paths: The name of the absolute paths under which the servlet is accessible as a resource
  e.g.:
  @scr.property name="sling.servlet.paths" value="/old/legacy/path"

Roberto Galoppini, blogger with a focus on open source topics, has written a post comparing MySQL's value proposition and licensing terms with Day's. Along more well-known considerations about GPL and its business implications Roberto discusses his observation that Day contributes to open-source projects, not products:

Why should we talk about Day Software? Actually they don’t pretend to be an open source vendor, but they do contribute a lot, both in terms of code and open standards definition and support. Simon Phipps’s score card would probably penalize them, but the problem here is that the score card is - quite wrongly in my view - about products instead of projects. Checking out Day’s contributions to open source projects on Ohloh gives a clear picture of why talking of Day makes sense in this context.

Some related articles:

• Roberto had previously interviewed David on the topic.
• Day and Open Source
• How Day Software stumbled upon an open source business strategy

Kas Thomas has hooked up the CK editor with Apache Sling (in the form of CRX) to produce a mini CMS in 64 lines of code. Neat hack!