Chapter 3. Working with Content Models

From setting up the initial content model to programmatically creating, searching for, and deleting content, how you work with the content in a content management system is a foundational concept upon which the rest of the solution is built. In this chapter, you'll learn:

• What a repository is and how it is structured

• How to make the underlying content model relevant to your business problem by extending Alfresco's out of the box model with your own content types

• What practices are the best for creating your own content models

• How to configure Alfresco Share to expose your custom content model via the user interface

• How to interact with the repository via the CMIS and JavaScript APIs

Defining SomeCo's content model

Recall from Chapter 1, The Alfresco Platform, that SomeCo is rolling out Alfresco across the organization. Each department has its own type of content to work with and different requirements for how it works with that content. SomeCo could just start uploading content into Alfresco. That would be better than nothing, but it doesn't take advantage of the full power of the platform, and makes for a really boring (and short) book. SomeCo would be better off formalizing the different types of content it works with by extending the Alfresco content model to make it SomeCo-specific.

Step-by-step - starting the custom content model with custom types

Let's start small and build the model up over successive examples. First, let's create a custom content type for Whitepapers, which are a type of marketing document. This is going to involve creating a content model file, which is expressed as XML, and then telling Alfresco where to find it using a Spring bean configuration...

Manage property indexing

Directly in your content model, you can specify how your properties will be indexed by Solr. Below each property, you can add an index element like this one (that contains the default value):

<index enabled='true'> 
    <atomic>true</atomic> 
    <stored>false</stored> 
    <tokenised>true</tokenised> 
</index> 

Here is the list of possible configuration:

• Change the enabled attribute to false to do not index this specific property. It means that you won't be able to search on it.

• Change the atomic property depending if you want properties to be indexed as part of the transaction commit (true), or indexed in the background (false). For example, the properties using  typed:content are indexed in the background because some transformations need to be done before indexing.

• Change the stored property if you want to store the property value in the index. This property should never be changed in production...

Modeling summary

A content model describes the data being stored in the repository. The content model is critical. Without it, Alfresco would be little more than a file system. Here is a list of key information that the content model provides Alfresco:

• Fundamental data types and how those data types should persist to the database. For example, without a content model, Alfresco wouldn't know the difference between a string and a date.

• Higher order data types such as "content" and "folder" as well as custom content types such as "SomeCo Standard Operating Procedure" or "SomeCo Sales Contract".

• Out-of-the-box aspects such as "auditable" and "classifiable" as well as SomeCo-specific aspects such as "rateable" or "client-related".

• Properties (or metadata) specific to each content type.

• Constraints placed on properties (such as property values that must match a certain pattern or property values that must come from a specific list of possible values).

• Relationships or "associations" between content...

Modeling best practices

Now that you know the building blocks of a content model, it makes sense to consider some best practices. Here are the top ten:

1. Don't change Alfresco's out of the box content model. If you can possibly avoid it, do not change Alfresco's out of the box content model. Instead, extend it with your own custom content model. If requirements call for several different types of content to be stored in the repository, create a content type for each one that extends from cm:content or from an enterprise-wide root content type.

2. Consider implementing an enterprise-wide root type. Although the need for a common ancestor type is lessened through the use of aspects, it still might be a good idea to define an enterprise-wide root content type such as sc:doc from which all other content types in the repository inherit, if for no other reason, than it gives content managers a "catch-all" type to use when no other type will do.In the case that Alfresco is being deployed across multiple...

Configuring the UI

Now that the model is defined, you could begin using it right away by writing code against one of Alfresco's APIs that creates instances of your custom types, adds aspects, and so on. In practice, it is usually a good idea to do just that to make sure the model behaves as you expect. But you'd probably like to log in to Alfresco Share to see the fruits of your labor from the last section, so let's discuss what it takes to make that happen. By the end of this discussion, you will be able to use Alfresco Share to work with the SomeCo-specific content model to do things such as these:

• Display and update custom properties and associations

• Create instances of SomeCo-specific content types

• Configure actions that involve SomeCo types and aspects

• Use Advanced Search to query with SomeCo-specific parameters

Configuring the UI to expose the custom content model involves overriding and extending Alfresco's out of the box Share configuration. To do this, you'll use different extension...

Working with content programmatically

Now the repository has a custom model and that model has been exposed to Alfresco Share. For simple document management solutions, this may be enough. But often, code will also be required as a part of your implementation. It might be code in a web application that needs to work with the repository, code that implements custom behavior for custom content types, code that implements Alfresco Share customizations, or code that implements a controller for a web script.

As mentioned in Chapter 1, The Alfresco Platform, there are several APIs available depending on what you want to do. Let's learn how to use code to create content, create associations between content, search for content, and delete content. You'll see a JavaScript example, several examples using the CMIS API with Java.

Step-by-step - creating content with JavaScript

The first example shows how to specialize some content and add aspects to that content using JavaScript. To specialize content...

Model manager

Alfresco provides an interactive tool to design your own custom model. It allows you to add custom types, aspects, and properties. On top of that, you can use the same tool to design the different forms for your content types and aspects. Open Alfresco Share and login as administrator, click on Admin Tools, click on Model Manager.

We are not going to discover how to use this tool but you'll notice that it follows exactly what we did to create our custom model manually. You could argue that it would have been easier to use this tool, instead of creating all these XML and properties file. However, I think that it's always important to really understand how it's configured and implemented from a pure technical point of view. Moreover, this tool doesn't cover all possibilities. For example, it's not possible to create association or child-association using this tool.

I would recommend this tool if you are looking for implementing a quick demonstration. But I don't think that it...

Summary

This chapter was about customizing Alfresco's content model, configuring Alfresco Share to allow end users to work with the custom content model via the user interface, and using the CMIS API to create, search, update, and delete objects in the repository. Let's recap what we specifically learned.

The Alfresco repository is a hierarchical collection of nodes.

The Alfresco content model defines the data types of nodes and properties, and the relationships between nodes.

Extending the content model to make it relevant to your business problem involves creating an XML file to describe the model, then telling Alfresco about it through a Spring bean configuration file.

The fundamental building blocks used to define the content model include: Types, Aspects, Properties, and Associations.

Best practices for creating your own content models include using aspects for re-usability, considering the use of a root content type, and leveraging the out of the box content model as a reference.

Configuring...