Lars Trieloff's Collaboration Weblog

In the first part of my micro-series I have come to the conclusion that a content-centric web application allows the user to interact with the content by the means of renderers and behaviors. These renderers and behaviors can be expressed by means of pipelines and processes.

A pipeline takes the existing content, transforms it several times and finally sends a new representation of the content to the client. This concept is anything but new, one of the most successful web application frameworks at apache is actually Apache Cocoon where pipelines are based on the idea of transforming XML events by means of XSLT, STX and other transformation languages.

Content behaviors can be seen as processes in the sense of business processes that trigger events, process input data and eventually manipulate content. A process can be expressed formally by a program or a script, or a graphical process programming language like BPMN.

If you take a look at a typical processing pipeline used by Cocoon, you will see something like this:

<map:match pattern="myThirdPipeline">
  <map:generate src="myXMLFile.xml" type="file" />
  <map:select type="resource-exists">
    <map:when test="myIncludeFile.xml">
     <map:transform src="myXML2include.xslt" type="xslt" />
     <map:transform type="include" />
    </map:when>
  </map:select>
  <map:transform src="myXml2PdfFile.xslt" type="xslt"/>
  <map:serialize type="fo2pdf"/>
</map:match>

The constructs involved here splits (<map:select>) conditions (<map:when>) and joins (</map:select>), activities ({<map:transform>}) can be found with different names in any workflow language, thus another way to interpret rendering pipelines is to see them as processes as well.

A content centric web framework's most important task is mapping content to processes and providing an execution environment for these processes.

(The FMC-construct used here is called structure variance. It means that the framework dynamically creates the renderer and behavior actors, depending on the content requested.) The framework maps a HTTP request to a content resource, identifies the process description for the kind of request ('real' processes that change resources for PUT, processes with side-effects for 'POST' and rendering processes for GET requests), e.g. a script or template file, dynamically instantiates the actor by interpreting the script or running the template engine and connects the request-handling actor to the content and the request and response.

In the next section of the series I will show how a framework like Sling handles request-to-content-mapping, content-to-process-mapping and how processes are enacted.