« links for 2007-10-24 | Main | Collaboration Conver... »

An architecture for content-centric web applications (Part 3)

posted 03:04PM Oct 24, 2007 with tags architecture jackrabbit jcr microsling sling webdevlopment by Lars Trieloff

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.

Comments:

Post a Comment:
Comments are closed for this entry.
« links for 2007-10-24 | Main | Collaboration Conver... »