Introduction

Content Front is a framework for rendering content from one or more Content Management System as HTML the correct way.

The main principle behind this framework is that each content type knows how to render itself in each perspective. For large sites with many content types appearing many places this is imperative for maintainability. The oposite is that each content element knows how to render all its children. This can be appropriate for small, isolated cases, but fails as soon as the number of combinations of content types and perspectives increase.

Content Front is not an another web application framework like Struts, Stripes, Spring MVC or Wicket - in fact, it will work well in combination with these frameworks. Apache Tiles is the framework that resembles Content Front the most - the difference is that Tiles doesn't have the concept of "Content". An earlier version of this framework used Apache Tiles as basis.

Content Front currently implements a connector to a Jackrabbit repository, and a static test repository using Spring XML files as "content". Implementing support for other repositories is relatively simple.

Features

• Renders content from CMS the correct way - each content type knows how to render itself in all relevant contexts
• Supports testable views - Static content can be defined using Spring, and JSP views are tested using a bundled Jetty container.
• Implements the MVC pattern
• Provides a structured way to render many content types in many different contexts.
• Render content from many CMS'es in a unified maner.
• Flexible parametrisation of views using Spring in setup, and using dynamic tag parameters when including content.
• Flexible caching of rendered content. Invalidation of cached nested content. Current implementation uses OSCache.
• URL handling - optional dispatcher filter to map URL to a content hierarcy.
• Content Front is not an application framework - for buttons and dropdowns look elsewhere.

10 second crash course

To render a content type, a view definition must exist. The view is defined using a custom Spring namespace:

The "jsp" attribute defines the view, the "class" attribute defines the controller, and the content using the template defines the model in this MVC implementation. Since the controller is a Spring managed bean, you can do all the fun stuff Spring allows you to.

To render the content, simply use the "render" tag from a JSP, with the content ID as parameter.

This renders the content using the default template defined for this content type. Take a look at the other sections for many more rendering features here !

Continue >>>