Alfresco One 5.x Developer???s Guide: Discover what it means to be an expert developer by exploring the latest features available to you in Alfresco One 5.x, Second Edition

The majority of document management solutions deal with files generated by an office suite. Of course, there are exceptions such as various types of graphics files, CAD/CAM drawing formats, and other specialized tools. But mostly, the files are generated by a small number of different tools and an even smaller number of different software vendors.

In the case of WCM, there is a wide variety of tools involved from text editors to integrated development environments (IDEs) to graphics programs with multiple vendors in each category. This means the WCM solution needs to be very flexible in the way it integrates with authoring tools. The alternative, which is forcing authors to give up their favorite tools in favor of a standard, can be a management nightmare.

WCM does not require the separation between content's appearance on the web site and its storage. But many implementations take advantage of this principle because it makes redesigning the site easier, facilitates multichannel publishing, and enables people to author content without web skills.

To understand why this is so, think about a website that has its content and presentation of that content merged together. When it is time to redesign the site, you have to touch every single web page because every page contains presentation markup. Similarly, content authoring is limited to people with technical skills. Otherwise, there is a risk that the content owner (for example, the person writing a press release or a job posting) will inadvertently clobber the page design.

One way to address this is to separate the content (the press release copy) from the presentation of that content. A common way to do that is to store the content as presentation-independent XML. The XML can then be transformed into any presentation that's needed. A redesign is as simple as changing the presentation in a single place, and then regenerating all of the pages.

The impact of separating content from presentation is three-fold. First, assuming the content consumers aren't interested in reading raw XML, something has to be responsible for transforming the content. Depending on the implementation, it may be up to the WCM system or a frontend web application.

Second, in the case of static content, any change in the underlying content has to trigger a transformation so that the presentation will be up-to-date, keeping in mind that there may be more than one file affected by the change. For example, data from a job posting appears in the job posting detail as well as the list of job postings. If the posting and the job posting index are both static, the list has to be regenerated whenever the job posting changes.

Third, content authors lose the benefit of WYSIWYG (What You See Is What You Get) content authoring because the content doesn't immediately look the way it will as soon as it is published to the web site. The WCM system, then, has to be able to let content authors preview the content as they author it, preferably in the context of the entire site.

A document management system is a lot like a relational database in the sense that it is typically an authoritative, centralized repository. There are exceptions, but for the most part, content resides in the repository and is retrieved by the systems and applications that need it. On the other hand, a WCM system often faces a publication or deployment challenge. Files go into the repository, but must be delivered somewhere to be consumed. This might happen on a schedule, at the request of a user, as part of a workflow, or all of the above. Granted, some websites retrieve their content dynamically; but most sites have at least a subset of content that should be statically delivered to a web server.

Let's look at an example of a basic corporate website. Most companies have a mix of About Us content that probably doesn't change very often, Press releases or News sections that might get updated daily, and maybe some document-based content such as marketing slicks, product information sheets, technical specifications, and so on. There's also some content that is used to build the site such as HTML, XML, JavaScript, Flash, CSS, and image files.

It is likely that there are several different teams with several different skill sets, all collaborating to produce the site. In this example, suppose the About Us and News pages come from the marketing team, the site is built by the web team and the document-based content can come from many organizations within the company.

Alfresco WCM sits on top of the core Alfresco product to provide additional WCM-specific functionality. An important distinction between Alfresco WCM and other open source content management systems (CMS) is that Alfresco is a decoupled CMS while something such as Drupal is a coupled CMS. This means that Alfresco manages the website but does not concern itself with presentation unlike Drupal, which is both a repository and a presentation framework. This doesn't mean that Alfresco can only manage static sites. You can easily query the repository in any number of ways. It just means it is up to you to provide the frontend from the ground up.

The add-ons are pieces of functionality not found in the core Alfresco distribution. If you are working with the binary distribution, it means you'll have additional files to download and install on top of the base Alfresco or Share installation.

Add-ons are provided by Alfresco, third-party software vendors, and members of the Alfresco community such as partners and customers. Alfresco makes several add-on modules available such as Records Management, Google Docs, Office Services or Kofax integration. Members of the Alfresco community create and share add-on modules via the Alfresco add-Ons (https://addons.alfresco.com/), a website set up by Alfresco for that purpose. At the time of writing, this website contains 444 different add-ons compatible with Alfresco Enterprise and/or Community.

When users log in to Alfresco, the first thing that is usually displayed is the My Dashboard section. The dashboard is a user-configurable layout that contains dashlets. (If you are familiar with portals, think portal page and portlet). Users choose the layout of the dashboard (number of columns) as well as the specific dashlets they want displayed in each column.

There are a number of dashlets available out of the box, or you can develop your own and add them to the user-selectable list. Examples of out of the box dashlets include workflow-related dashlet such as My Tasks as well as content-related dashlets such as My Documents, My Sites or My Activities:

Currently most of these dashlets are Spring Surf Dashlets (http://docs.alfresco.com/5.1/concepts/dev-extensions-share-surf-dashlets.html), but they will eventually be converted to Aikau Dashlets (http://docs.alfresco.com/5.1/concepts/dev-extensions-share-aikau-dashlets.html). Aikau is the new UI framework developed by Alfresco, and available from Alfresco 4.2.Some of these existing dashlets allows you some configuration. Here are some examples:

Obviously, developing custom dashlets is probably not something you'd let your business users do; but it is still considered a basic customization. It can be complex to develop new dashlet depending if you need to develop new web script for example.

The first concept that you'll discover using Alfresco Share is the concept of site. It's a secured area in the repository where a team, a project or a suborganization can share and manage any kind of contents, including documents of course. A site includes multiple pages, depending mainly of the type of content. Alfresco Share provides the following by default:

In each site, you can configure and select only what is needed by the users.

Each Alfresco Share site contains as well a dedicated dashboard that you can entirely customize with all out-of-the-box dashlets already provided.

A rule is something that says, "When a piece of content is created, updated, or deleted, check these conditions. If these conditions are met, take these actions". Conditions may check whether a piece of content is a particular mime type, or a specific content type. They may also check whether a piece of content has a specific aspect applied, or whether the content's name property matches a particular pattern. Rules can be defined on any folder in the repository. Child folders can inherit rules from their parent.

Rule actions are repeatable operations that enable us to do things similar to those that can be done using JavaScript or Java. Out-of-the-box actions include things such as check-in content, check-out content, move an item to another folder, specialize the type of the content, add an aspect to the content, transform content from one format to another, and so on.

Configuring folders to run rule actions is something non-technical users can do through Alfresco Share. In Chapter 4, Handling Content Automatically with Actions, Behaviors, Transformers, and Extractors, you'll learn how to write your own custom rule actions using the Alfresco API.

Alfresco has two options for implementing workflow: simple workflow or advanced workflow. The good thing about simple workflows is that end users can configure them as needed without any technical skills or developer support.

Here's how it works. A user creates a rule to add simple workflow to a document when it is placed in the folder. When an item enters a folder with this type of rule applied, it will have additional UI action items available. The rule to specify the user actions and flow of the content between folders is configured in the repository action. When the step is invoked, the content can be copied or moved to another folder. It's also possible to add complexity to a simple workflow by creating rules for other folders and passing content around from location to location. For example, there might be folders called Draft, In Review, and Approved. The state of a document is determined by the folder in which it resides.

Simple workflows have obvious limitations:

The advanced customizations are the customizations that are likely to require code. They are the focus of the book. To give you an idea of what's possible (and in an effort to provide an appetizer before the main meal is served), let's go over some of the areas of advanced customization.

Alfresco's out-of-the-box content model can be extended to define your own content types, content aspects, content metadata (properties), and relationships (associations). The out-of-the-box model is very generic, and defines only a minimal subset of the metadata that will probably need to be captured with the content.

For example, SomeCo might want to capture different metadata for its marketing documents than for its HR documents. Or maybe there is a set of metadata that doesn't belong to any one content type in particular, but should rather be grouped together in an aspect and attached to objects as needed. These and other content modeling concepts will be covered in Chapter 3, Working with Content Models.

There are several hooks or places where you can insert logic or take action to handle content automatically. These include rule actions, behaviors, content transformers, and metadata extractors. Rule actions have already been discussed. Behaviors are like actions but instead of being something that an end user can invoke on any piece of content, behaviors are tightly bound to their content type or aspect. Content transformers, as the name suggests, transform content from one format to another. Metadata extractors inspect content as it is added to the repository, and pull out data to store in the content object's properties. These tools for handling content automatically will all be covered in Chapter 4, Handling Content Automatically with Actions, Behaviors, Transformers, and Extractors.

Chapter 5, Customizing Alfresco Share, covers Share customization. Just about everything in the Share web application can be tweaked. In the document library, it's possible to configure the view of a content, or the edit form depending of the content type. It's possible as well to define a template renderer that changes the default view in the document list. Alfresco Share provides as well different views that you can customize, or even create new ones. And if you want more, you can even create your own page from scratch.

Web scripts are one of the more exciting additions to the Alfresco architecture. The reason is that RESTful services are typically much easier to work with using scripting languages and AJAX toolkits than SOAP-based services, because they are invoked through plain old URLs.

The web script framework, based on the Model-View-Control (MVC) pattern, allows you to build your own RESTful API to the repository. It will be covered in detail in Chapter 7, Exposing Content through a RESTful API with Web Scripts, but the high-level summary is that URLs get mapped to a controller implemented as JavaScript or Java. The controller performs whatever logic is needed, then forwards the request to the view. The view is implemented as a FreeMarker template. The template could return anything from markup to XML to JSON. RESTful services via web scripts are the preferred way to integrate with the Alfresco repository.

Advanced workflows provide a way to automate complex business processes. Alfresco's advanced workflows are executed by the embedded Activiti engine, which is a very powerful and popular open source workflow engine.

Rather than basic workflows, which are end-user configurable and limited to serial processes, advanced workflows offer the power of parallel flows, the ability to add logic to the process via JavaScript and Java, and much more.

A handful of advanced workflows are available out of the box. These are most useful as starting points for your own custom advanced workflows. Exactly how it has to be done will be covered in Chapter 8, Advanced Workflows.

Most of the coding and configuration discussed so far can be divided into two parts:

There is a third bucket to be considered, which is coding and configuration related to integrating Alfresco with other solutions. Maybe Alfresco needs to authenticate against an LDAP directory. Maybe a portal will get its content from Alfresco, or perhaps some other third-party application needs to share content with Alfresco. Chapter 9, Amazing Extensions,discusses how to handle security and integration.