Web projects are the production-side representation of a site. This is what manages the content consumed by the site. Here the access rules and roles for content producers are defined. Every Alfresco server can have multiple web projects. Within a web project the user can:

These actions can be controlled and managed through the use of workflows.

Alfresco provides a sandboxed development model. Content producers make use of the sandboxes to make changes to a site in isolation from one another. The default configuration is as follows:

Virtualization and In-context Preview is core to the sandboxing concept. Virtualization means that each user has a complete view of all current, approved, checked in content along with those unique modifications made within the context of their sandbox. Alfresco provides a complete virtual view of the website as it would look if all changes in a sandbox were committed to the live site even when previewing any non-modified or modified asset in a sandbox. This is In-context Preview.

Each user in the context of their sandbox can do rigorous and thorough quality checks for all changes they are posting to the website.

Transparent layers are the means to implement sandboxes in Alfresco. This layer is a central construct in the Advanced Versioning Manager (AVM) repository, very similar to the UnionFS Linux filesystem, and is used to define "composite" stores that can "read through" content from other stores. It can be defined at the store, directory, or file level.

From Alfresco 3.1 onwards, transparent layers can be configured by a Content Manager in the Staging Sandbox of a web project. This is useful for:

Web forms are used in Alfresco WCM to capture content from the user, and store as XML. An XML schema needs to be created by form developers for capturing content. It is then rendered automatically as a user-friendly web-based form for content contributors.

Alfresco uses the open source project Chiba, an XForms implementation used to transform the XML schema into an internal representation of a form (XForms), and then present UI controls for elements and attributes described in the schema. This helps to render the form entry UI to the end users.

Web forms are created and administered in the Web Forms space within the Data Dictionary. As they are located in Alfresco Spaces, they are accessible by the default CIFS, FTP, and WebDav interfaces. They can also be configured with rendering engine templates for generating renditions of the collected content.

The web form-managed XML can be transformed with rendition templates and the corresponding content into rendered output. Server-side templating languages, such as FreeMarker, XSLT, and XSLT-FO are provided by Alfresco. After a content item (XML file) is created via a web form, each rendition template configured for that content type is executed, producing an output file per template (shown in the following diagram). Typical formats for renditions of web content include HTML, JSP, PDF, XML, and so on:

Web scripts provide RESTful access to content held within your Alfresco Enterprise Content Repository. You can therefore place controls on your enterprise content to manage it, and provide uniform access for a wide variety of client applications and services, such as browser, portal, search engine, or any custom application.

Web scripts allow you to:

Alfresco WCM uses JBoss jBPM for all workflows. There are three aspects of workflows in Alfresco:

In Alfresco there are three delivery models: static, dynamic, and a hybrid of both static and dynamic. In a static delivery model, all requests to the web server return a static file of XHTML, XML, JSON, and so on to the web client without any additional processing (no CGIs, no SSI, and so on).

In a dynamic delivery model, all requests to the web server return objects of type XHTML, XML, JSON, and so on that are processed by some application server to render the resulting document.

Static delivery model

In such a model, pages are rendered as part of the content production process. The resulting HTML and associated assets (images, CSS, JS, and so on) are then published to the filesystem, typically a document root of a web server. This provides high levels of scalability on simplified production architectures (web server farms). This model, however, has limited personalization and there is a set number of rendering technologies (FreeMarker, XSLT, and XSLT-FO).

A File System Receiver (FSR) will need to be installed and configured to receive published static content from the Alfresco server. The FSR consists of a small server that receives updates from an Alfresco repository and publishes them to a flat filesystem, which is then typically served up by a web or application server. The following diagram illustrates this process:

Dynamic delivery model

A pure dynamic model publishes content to an Alfresco Runtime, thereby making the content available for dynamic queries with basically any web technology (PHP, Python, J2EE, AJAX, Flash, Cold Fusion, and so on). This provides ultimate flexibility in what and how content is displayed on a page. This provides the highest levels of personalization, but will require significantly more resources on the delivery servers for similar levels of traffic. For all but the smallest websites, significant effort is required in architecting, developing, and testing to ensure website or application stability. This is particularly the case during unexpected high-volume situations (for example, a Government website during a national disaster). The following diagram illustrates the dynamic delivery model:

An Alfresco System Receiver (ASR) will need to be installed on a server to facilitate the dynamic delivery model. The ASR is just another instance of the Alfresco server. The ASR allows a web project being authored in one Alfresco server instance to be deployed to another separate instance of Alfresco.

The best of both worlds

A hybrid approach is the preferred approach regardless of the WCMS and the underlying technologies. Determination of what is static and what is dynamic is highly dependent on the type of website and web applications.

Users also have the option of a hybrid delivery approach. This approach can be executed as follows:

• The web architecture model should be designed to support the dynamic model. This includes the ability to deploy content to both filesystems and Alfresco runtimes for flexibility.

• Leverage the static model wherever possible. If content must be personalized to a single user or a very small set of users with few "page" impressions, it most likely needs to be dynamic. Otherwise, it can be static.

• Choose a page composition model appropriate to the overall site and each page on the site:

  • Outside-in: Each page is static HTML with static components already embedded, but dynamic components or applications such as AJAX and Flash can be included.

  • Inside-out: Each page is dynamic and includes all page components dynamically regardless of whether those components are static or dynamic.