Content Creation

Document created by resplin Employee on Jun 6, 2015
Version 1Show Document
  • View in full screen mode

Obsolete Pages{{Obsolete}}

The official documentation is at:



This page described plans for implementing the first release of Alfresco WCM.  It is now superseded by actual product documentation. 


Alfresco will be providing authors and reviewers with the ability to create and modify structured data (XML). Administrators will be able to configure the system so that content modification only occurs within the context of task-specific workflows. By integrating template-driven content generation with a dependency manager, Alfresco will simplify the process of keeping data in sync throughout website, and make it highly scalable.

The mechanism for capturing and presenting structured data will be modular and extensible.  Alfresco will be providing a reference implementation using XForms  for data capture, and the FreeMarker Template Engine for content presentation.  Either subsystem (or both of them) may be replaced with something else  (e.g.:  you might want to use Velocity instead of Freemarker).  The minimal requirement is that each XML data type be registered with Alfresco, and that the XML data type be described by an XSD.

Form Processors

Alfresco will provide a reference implementation of data capture using an XForms processor.  XForms is a natural choice for capturing structured content:

  • The form is described in XML.
  • The XML schema/model (XSD), XML content (instance data), and the user interface are all separate.  This allows us to use the same XForm to capture multiple XML documents, and to have multiple XForms capture the same XML schema/model (if necessary).
  • XHTML content (including Javascript and CSS) can be interspersed within XForms, providing customers with the ability to customize the data capture UI.
  • Interdependencies between inputs can be specified.  XForms supports a rich event model which allows for communicating changes in state between inputs in a form, and processing validation on those inputs.
  • Supports repeated items, and provides triggers for inserting and deleting repeated item instances.
  • Provides a rich set of data types (such as URIs, dates and numbers), and a rich set of built-in functions for performing validation and implementing dependencies among controls.
  • Provides a rich set of abstract UI controls, such as ranges, inputs, uploads, and selects (single and multiple).  These controls aren't explicitly bound to UI implementations (e.g.: radio buttons, text areas, etc.).   This enables the same XForms description to be implemented in different ways, potentially on different types of devices.
  • Supports serializing form data in multiple ways during submission such as XML data, or URI-encoded data.

The XForms implementation we'll be using is Chiba.  Chiba provides a number of features that makes it a great fit:

  • Conforms to most all of the XForms 1.0 W3C Recommendation.
  • It's open source and maintained by friendly people who monitor their mailing lists.
  • Provides two implementations of the XForms UI: one that provides static HTML for non-javascript enabled browsers, and another that provides a rich AJAX interface.
  • There's chatter that they'll be integrating TinyMCE (a JavaScript rich text editor) into the AJAX UI implementation.  This would provide a mechanism for collecting XHTML content from users.  I'm not sure what the status of this integration is, so if someone else isn't doing it, we'll have to coordinate integrating it with the Chiba people.
  • The UI generated by the Chiba Web package can be customized to provide a look and feel consistent with Alfresco.
  • Provides an XSD to XForms converter.

RDanner:  I have an integration between chiba and tinymce but I am not real happy with it.  There must be a better way to do it than what we currently have.  Our implementation has a couple of bugs.  If someone at alfresco is working on it I would like to talk to them and see what type of progress they have made.  Initially the integration is kind of simple (integrating TinyMCE is usually simple) but it gets kind of messy with Chiba because you are not operating in the traditional post based web environment.

Rendering Engines

Those who design for scalability often wish to pre-generate as many HTML/PDF files on their website as possible. This allows most pages to be served as flat files by cheap server farms, rather than by more resource-hungry application servers.  It also increases reliability at runtime on the live site, improves QA, provides a better audit trail, and avoids exposing users to timeouts (e.g.:  caused by lengthy jsp recompilations after modifications are deployed).  Therefore, while some fraction of a website consists of pages created 'on the fly', scalable solutions usually depend quite heavily upon pages generated statically based on templates.

The association between raw input and compiled output will be tracked via a build-in dependency manager.  This approach will permit users (or programs) to perform operations like:

  • Determine which generated files are 'stale' relative to their data source(s)
  • Recompile 'stale' files using the proper templating engine(s)
  • Audit file generation (i.e.: which tools does this site really use, and how?)

As with data capture forms, Alfresco's template compiler will be pluggable.  We will most likely be providing not one, or two, but three reference implementations for template compilation.


The FreeMarker Template Engine will probably be our default rendering engine (see the FreeMarker website for more details).   Some of the things we like about FreeMarker are:

  • A 100% Java implementation, which makes it completely embeddable within Alfresco.
  • Alfresco already uses it
  • Complete separation of templating markup from code
  • Simplicity relative to tools of equivalent expressive power. 
  • Similarility to JSP, and an expression language similar to the JSP expression language.
  • It's designed for manipulating DOM tree's which is exactly what we want for processing XML structures into XHTML pages.
  • It restricts users to a basic set of operations useful for generating HTML, which while preventing developers from accessing the more low level features of java directly, makes it more unlikely that forms will present security exploits and access JVM features that could interfere with usage of Alfresco by other users (by calling things like System.exit()).


Using features provided by our virtualization technology, we should be able compile JSP on the fly without requiring the developer to load their JSP directly into a web application.  This will allow us to offer JSP as a presentation technology to those developers who are accustomed to JSP and don't want to learn FreeMarker.  As part of this integration, we will be placing the DOM tree representing the captured XML on the PageContext under a well-known key before evaluating the JSP page.


We will also be providing an option to use XSLT as the presentation technology.  We'll use whatever XSLT processor is configured for the web application (which will most likely be Xalan).  XSLT is a natural choice for transforming XML content into XHTML for most scenarios that do not involve complex interaction with the world outside the XSLT environment.

Defining Content Types

Content types will be described by and XML Schema (XSD).  The XSDs will be stored in a magic folder within the Data Dictionary.  A wizard will assist developers in registering new content types with Alfresco.  The wizard will have the following steps:

  1. The user will be prompted to provide a human-readable name for the content type.
  2. XSD selection:  the user will have the choice of uploading an XSD, importing one from somewhere within the repository, or creating one on the fly.  Ultimately, the XSD will be placed in a directory within the Data Dictionary section for XML Content Types with the name provided in step 1.
    1. If the user chooses to generate a schema on the fly, Alfresco will provide a UI for describing a basic XSD, describing the properties to capture, and their types.  Basic validation attributes  will also be collected, such as  how many instances of the property are to be captured, and whether or not the property is required.
  3. The user will be asked to associate a data capture implementation with the content type.  By default, if only our reference XForms implementation is available, we will skip to step 3.1.  There must be exactly one data capture implementation selected and configured.
    1. With XForms, we will prompt the user for an form to upload, or provide an option to generate one based on the XSD provided (using Chiba's Schema2XForms).  A dependency will be made between the form and the XSD.  If a change is made to the XSD, we will have a configurable process for notifying the author that changes may be required to the form.  Because the form will be stored in the repository, the developer can modify its presentation logic and/or validation code.
  4. The user will be asked to associate zero or more presentation templates with the XSD.  The first screen will provide a set of radio buttons, one for each presentation template implementation (JSP, FreeMarker, XSLT), and one to proceed without configuring a presentation template (this supports the use case where XML data is simply being captured, not presented).
    1. If the user has chosen to configure a template, they will be prompted to upload a file for that template, or to import one from within the repository.  They will also be prompted to provide a human-readable description of the template (e.g.: 'generates HTML', 'generates HTML without a table of contents', 'generates a PDF', etc.).  The template will reside in the repository, and can be versioned the same way any asset can be.  A dependency will be made between the template and the XSD, and will trigger a configurable process if the XSD is modified.
    2. The user will be presented with a list of configured templates.  The user will be able to change which is the default template.  The user will be asked whether or not they want to configure an additional template.  If they want to configure another template, they will return to step 4.1.  Otherwise they will proceed to step 5.
  5. The user will be prompted to select which workspaces/users this template should be made available to.

To override the default data capture and/or presentation implementations, the customized implementation must be registered within a configuration file (to be determined).

Create Web Content Flow

Alfresco will provide a Create Web Content wizard and provide an option for creating an XML asset. The wizard will continue with this flow:

  1. The first screen of the wizard will be identical to the Create Content Wizard, other than the dropdown containing HTML and Plain Text will have an option for creating XML
  2. If XML is selected, the user will then select the content type of the XML asset to create.
  3. The data capture implementation associated with the content type will be used to generate data capture UI which will walk the user through filling out the form and perform any necessary validation.  Once the user has filled in the form so that it validates successfully, the asset will be saved in the user's workspace, and a dependency will be created between the asset and the XSD to track any future changes to the content type.  From this screen, the user will also have the option to preview the generated content for this form if a presentation template is associated.  Previewing content will utilize Virtualization.  If the user clicks save, both the XML data and the generated HTML will be saved to the workspace.  A dependency will be made between the XML data and the generated asset.
  4. A summary will be displayed consistent with the current Create Content wizard describing the assets created.
  5. The user will be presented with the tagging screen as in the current Create Content wizard.
  6. The user will be prompted to attach the asset to a submit workflow, or to just leave the asset as modified in the workspace.

Dependency Management

Alfresco will provide a built-in dependency manager that tracks the relationships between files and the programs (and associated parameters).  Dependency management is complimentary to lower level build systems;  in a sense it performs the inverse operation. While a build system such as Ant or make let you say:

  • Here's how a logical build operation named 'X' is implemented
  • What would happen if I performed logical build operation 'X'?
  • Perform logical build operation 'X' (which then generates a set of output files)

Alfresco's dependency manager will let you say:

  • Here's the dependency logic used to determine whether a file named 'Y' is stale
  • Here's the build rule that must be invoked to regenerate the stale file 'Z'
  • Of a specified set of files, which ones are stale relative to their respective data source(s)?
  • Invoke the minimum set of build processes needed to regenerate a set of stale files

A URL-based and Java-based API will allow applications to integrate with the dependency manager.  The means used to determine what files are 'stale' relative to their data source(s) will itself be pluggable.  By default, we'll offer SHA-1 and modification time based methods, but we'll also supply hooks for arbitrary functions (e.g.MD5, GPG signatures, etc.). Multi-level dependencies will also be supported (e.g.: A depends on B, which depends on C and D).  Build rules themselves will be expressed as URLs, to facilitate scripting, integration with third-party tools, and distributed compilation.

Workflow-Driven Processes

Even in small organizations, many (if not most) web content creation activities should occur within the context of a workflow.  Therefore, Alfresco will probably incorporate a full-featured workflow system such as JBoss jBPM when it announces official support for WCM.  Default workflows and examples will be supplied in order to illustrate:

  • Automating website policies
  • Capturing required metadata fields
  • Performing data validation
  • Enforcing editorial review processes
  • Executing rebuild/redeployment logic

We are currently in the process of revising our content repository.  When this effort is complete, Alfresco will allow users to preview the entire website with their own personal contributions superimposed upon it without disturbing anyone else.  Similarly, administrators will be able to preview timed deployments in-context, prior to actually moving any files to the live website.