Lars Trieloff's Collaboration Weblog

Congratulations to Michael Marth for the successful softlaunch of dev.day.com, the developer portal for all things related to Jackrabbit, JCR, CRX, Sling and Microsling. The first part in the picture is a blog with the witty title "content goes here", which is Day's first step into blogging and will definitely not the last one.

If you are interested in Jackrabbit, JCR, Sling, content management and all the other exciting stuff we do at Day, point your feed reader to http://feeds.feedburner.com/contentGoesHereBlog.

Dave Johnson's wrap-up of the ApacheCon contains some interesting pieces: Of course he mentions the Shindig proposal, which I hold as one of the most interesting developments in the social networking space and he has written a longer paragraph on combining Roller (the weblog software) and Jackrabbit (the JCR repository that is the core of Day's CRX).

The idea of using a content management system to store Roller content keeps on coming up. At ApacheCon EU earlier this year, I spent some time talking to Lars Trieloff (who now works for CMS vendor Day Software) about implementing the Roller back-end interfaces using the Java Content Repository (JCR) APIs instead of the Java Persistence API (JPA) that we use now.

My rationale then was, to allow true free form collaboration in Mindquarry, we needed a weblog system. Mindquarry is based on Jackrabbit and I did not want to open another repository backend then, so I thought about creating a JCR-based backend for Roller that would easily integrate with Mindquarry.

At this ApacheCon, Noel Bergman brought up the topic a couple of times and pointed out that Day Software, has blog and wiki modules that are both backed by JCR. We could do the same thing: create version of Apache Roller and Apache JSPWiki (incubating) that share the same content repository.

The main advantage is that Roller and JSPWiki are content-centric applications. Every well-designed content-centric application moves sooner or later into the direction of having a separate repository layer. In JSPWiki the repository-layer allows you to have different backends, from flat files, to RCS to Apache Roller. In Roller there is a domain-specific repository implementation that is called "model", but if you have read my recent posts on microsling, you will note that using Model-View-Controller (MVC) for content-centric applications is disgusing the content-centric nature of the application, which would need a Content-Behavior-Appearance (CBA) model.

Later, Jukka Zitting (who also works for Day Software), suggested the idea of implementing JPA itself with JCR, thus allowing Roller to store its content in a CMS in a totally transparent fashion. This topic is interesting to me, but I don't fully understand the benefits of backing blogs and wikis with JCR. What new use cases would this support? How do the interesting features of JCR, like versioning for example, bubble up through Roller -- especially if Roller is to support both RDBMS and CMS back-ends?

I had a chat with Jukka yesterday in which he pointed out that implementing JPA based on JCR could be a very-cost effective solution and it might be the ideal way to go to migrate applications stuck with relational or object-relational backends to a content-based backend. Of couse, you would lose many of the advanced features that JCR offers you like full-text-search, observations, versioning because you have to mainatain backwards-compatibility to relational databases.

As always, this is a questions of frameworks and the right time to start a project. When the Roller project was started, there was no JCR, no Sling and no practical and standardized way of implementing content-centric-applications. With this in mind, it is easy to map some of the features JCR is offering to the needs of a blog application:

versioning

keeping all versions of a blog post, allowing incremental writing and backup

observations

notifications for new comments

workspaces

having a draft and a publish area for posts

hierarchy

posts belong to weblogs, comments to posts, etc.

export

backup

queries

tagging, categories, full-text-search

Disclaimer: I am Day's product manager for collaboration products, namely Blog and Wiki and I am a long-time user of Roller and JSPWiki. This blog post was written on Roller, using the JSPWiki plugin.

In the first sections of this series we learned the basics of content-centric architectures and how a content-centric framework looks like. In this iteration I am going to take a closer look at microsling and show how it maps structured data of different types.

The data microsling deals with has following natures:

• HTTP Requests
• HTTP Response
• JCR Nodes
• Scripts (Behaviors or Renderers)

The first part of this mapping discussion will only cover mapping of HTTP requests to JCR Nodes.

Mapping HTTP Requests to JCR Nodes

A simplistic description of a HTTP Request can be described as "A request URI, a request method and a number of named request parameters". A JCR node can be described (again grossly simplified) as "A resource path and a number of named properties and a number of named child nodes". Following data will be mapped:

• request URI to resource path (called content resolution)
• request parameter to property

Content Resolution

The guiding principle for content resolution in microsling is that for every request path, there is at least one resource path that is a substring of this request path. microsling tries to find the longest resource path that is a substring of the request path, using / and . as path delimiters. For instance, for the request path /weblogs/lars/entry/an_architecture_for_content_centric2.html/view following resource paths are possible:

• /weblogs/lars/entry/an_architecture_for_content_centric2.html/view
• /weblogs/lars/entry/an_architecture_for_content_centric2.html
• /weblogs/lars/entry/an_architecture_for_content_centric2
• /weblogs/lars/entry
• /weblogs/lars
• /weblogs
• /

because of the final fallback to / you can be sure, there is always content that can be mapped to a request path.

However, whatever content path has been found, some additional information will be made available for request processing. This information is:

• The extension: In this case the extension would be html. This comes handy, when delivering more than one representation for one resource, for instance in a web calendar the extensions html, json, atom, ics come to mind.
• The selector: The selector is everything that comes before the extension, but is prepended by a dot. This allows selecting more than one view for one extension, for instance /weblog.html would give the standard view of the weblog entries, but /weblog.gallery.html would create a photo-gallery for a photo weblog. There can be more than one selector at the same time, e.g. /weblog.archive.1.html
• The suffix: basically everything that comes after the extension, in the above example /view. With the suffix you could for instance address parts of a resource.
• The unused content path. If for instance the request path in the above example has been resolved to /weblogs/lars/entry, /an_architecture_for_content_centric2 would be the unused content path. With this information you could create an error page or a form that allows you to create the non-existing weblog entry.

Property Resolution

microsling maps request parameters in some cases to properties of a content node. This is a useful way of creating new content nodes or updating existing nodes with a simple form. The default mapping will map every single-value request parameter to the same name node property. Multi-value request-parameters are mapped to multi-value node properties. New nodes created during this mapping will have the type nt:unstructured, basically allowing every content type.

In the next series I will cover mapping of content to scripts, called script resolution.

I've uploaded my second presentation "Mindquarry for Cocoon Users" to slideshare.net. And as far as I see, Ugo has added his presentation to the Cocoon group at slideshare.net as well.

We recently released Mindquarry 1.1beta. Most of the changes center around the user interface.

• we have re-worked the user interface using an UCD-process. In my point of view this gives us a much better usability and has made me from an user-centric-design agnostic to a true believer in UCD.
• Activity timeline (based on the SIMILE Timeline) to view older versions of files, Wiki pages, tasks. When I saw Stefano's presentation at ApacheCon Europe I learned that the SIMILE folks created this widget to lure ingenuous developers into creating a web of data. The widget is really easy to use, I only had to write a small wrapper script to turn it into a Dojo Widget for SIMILE Timeline.
• Include tables and images in Wiki pages. This is a side-effect of the transition to Dojo 0.4.1 that Jeremy contributed to Cocoon in January and that took us some time to pick up, because the API and implementation of the servlet services we are using heavily had changed (before they were called block servlets)
• Conveniently link to a file, a task or another Wiki page from within the Wiki. In the window for adding a link, you can search for the item you intend to reference. This is another heavy Dojo widget that uses the JSON data we produce internally.
• Desktop client for Mac. The Desktop Client for Mac 1.1-beta included a bug, this is why I released 1.1-rc as a release candidate today.

Especially the activity timeline is a huge step forward for us, because it brings us closer to our goal of an ultimate undo/redo of all collaborative content within Mindquarry. This allows teams to have full revision control and provides a good overview of a team's productivity. We are already versioning all contents since 1.0 thanks to the ease of versioning JCR and Jackrabbit provide and have found a convenient interface to access this data using the timeline widget.

The Mac client has proven to be very useful while testing it internally at Mindquarry. Most of us run Mac OS X and of course we use Mindquarry for daily work to share files. My colleagues especially like that they can now easily comprehend which files have been added by others to the server's files repository and also see the changes to the local copy they made to the repository on their computer. Simply by hitting the "Synchronize" button, they can commit and retrieve changed or added files. Furthermore, they also value that they can use the Mac client to manage tasks offline and synchronize once back online again.

You'll find more information about this release on the Mindquarry 1.1 Release page. This release would have been impossible without the great work of open source communities of our core components, especially the Apache Cocoon, Apache Jackrabbit and Dojo Toolkit community.

So far it has been a great conference. I hda the opportunity to meet many interesting people, have many interesting discussions, among those the BOF of the text processing crowd that discussed details of the incubated Tika project, a content-extraction engine that can be used in search engines like Nutch, in ECM and document management servers and other tools. Once again I took the opportunity to get some code done with Jeremias by updating Batik's POM to the latest release which is among other things able to process the Tango Icons, so it will be possible soon to process icons using Cocoon and Batik on the fly to generate PNG or GIF buttons.

Friday, 2pm, I will give a 15-minutes-presentation in the fast feathers track about lessons learned integrating Cocoon, Jackrabbit and Solr, the Apache projects we have been involved most closely when implementing Mindquarry and I hope to see you there and share experiences.

When you are building applications using Spring and JCR with a repository like Apache Jackrabbit, the newly released JCR Spring module (see org.springmodules: spring-modules-jcr 0.7) might be for you.

It contains Spring FactoryBeans that allow you to access JCR repositories directly, via RMI or JNDI.