When implementing content management solutions using Alfresco, one of the many useful features that it offers is “aspects”. Aspects are used extensively in Alfresco content models as commonly-used building blocks from which content types can be made.

Something that is, perhaps, less well known is that the XML schema of an aspect definition is almost identical to that of a type definition other than the fact that a type may have a set of mandatory aspects whereas an aspect may not (see the file “modelSchema.xsd”).

This means that an aspect may have a parent aspect. It also means that it may override the properties of its parent aspect. The ability to override the parent’s property definitions can be very useful. One may add additional constraints or make a property mandatory, for example. A particular use for this ability that I’ve come across on virtually every Alfresco project that I’ve been involved in concerns the standard Alfresco aspect “cm:titled”.

The cm:titled aspect is defined in “contentModel.xml” as follows:

      <aspect name="cm:titled">
         <title>Titled</title>
         <properties>
            <property name="cm:title">
               <title>Title</title>
               <type>d:mltext</type>
            </property>
            <property name="cm:description">
               <title>Description</title>
               <type>d:mltext</type>
            </property>
         </properties>
      </aspect>

These are very handy properties – virtually all organisations that want a content management system want their documents to have titles and descriptions. It’s also the case that the Alfresco web client has these two properties on its advanced search form by default, and automatically adds this aspect to every piece of content that is created using the web client indirectly via the “app:uifacets” aspect. So it’s a commonly used aspect that’s available out of the box. Wonderful.

Well, it’s almost wonderful. The problem is that on every project that I’ve worked on, the organisation for which we are building an Alfresco solution really wants “title” and “description” to be mandatory properties. As one can see from the definition above, the properties defined on the cm:titled aspect are not mandatory.

We can use the ability to base an aspect on another aspect along with the ability to then override the parent’s property definition to our advantage here. Let’s define a new aspect based on cm:titled:

      <aspect name="myapp:titled">
         <title>Titled</title>
         <parent>cm:titled</parent>
         <overrides>
            <property name="cm:title">
               <mandatory>true</mandatory>
            </property>
            <property name="cm:description">
               <mandatory>true</mandatory>
            </property>
         </overrides>
      </aspect>

All we’ve done here is override both title and description to be mandatory. Now if we apply this aspect to an item or add it as a mandatory aspect to a custom type then these properties become mandatory for that item or type.

This is just one example where the ability to derive new aspects from existing ones is useful. Additionally, one could apply new constraints such as one that checks that the title is more than one word long, for example.