Step-by-Step: Relating Types with Associations

SomeCo has a generic need to be able to identify documents that relate to each other for any reason. A Whitepaper might be tied to a solution offering data sheet, for example. Or maybe a project proposal the Legal department has should be related to the project plan the Operations team is managing. These relationships are called associations.

Let's update the model file to include a related-documents association in the sc:doc type so that any SomeCo document can be related to any other.

To add assocations to the model, follow these steps:

  1. Edit the scModel.xml file.
  2. Add the following associations element to the sc:doc type. Notice that the target of the association must be an sc:doc or one of its child types. The association is not mandatory, and there may be more than one related document: 
        <type name="sc:doc">
      <title>Someco Document</title>
      <parent>cm:content</parent>
      <associations>
       <association name="sc:relatedDocuments">
       <title>Related Documents</title>
       <source>
        <mandatory>false</mandatory>
        <many>true</many>
       </source>
       <target>
        <class>sc:doc</class>
        <mandatory>false</mandatory>
        <many>true</many>
       </target>
       </association>
      </associations>
    </type>
  3. Save the model file.
  4. Deploy your changes using ant deploy and restart Tomcat.

When you restart, watch the log for errors related to the content model. If everything is clean, keep going.

Associations

Associations define relationships between types. Without associations, models would be full of types with properties that store "pointers" to other pieces of content. Going back to the expense report example, suppose each expense is stored as an individual object. In addition to an Expense Report type, there would also be an Expense type. In this example, associations can be used to tell Alfresco about the relationship between an Expense Report and one or more Expenses.

Note

Here's an important note about the content model schema that may save you some time: Order matters. For example, if a type has both properties and associations, properties go first. If you get the order wrong, Alfresco won't be able to parse your model. There is an XML Schema file that declares the syntax for a content model XML file. It is called modelSchema.xsd, and it resides in the Alfresco web application under WEB-INF|classes|alfresco|model.

In the sc:relatedDocuments association you just defined, note that both the source and target class of the association is sc:doc. That's because SomeCo wants to associate documents with each other regardless of content type. Defining the association at the sc:doc level allows any instance of sc:doc or its children to be associated with zero or more instances of sc:doc or its children. It also assumes that SomeCo is using sc:doc or children of that type for all of its content. Content stored as the more generic cm:content type would not be able to be the target of an sc:relatedDocuments association.

Associations come in two flavors: Peer Associations and Child Associations. (Note that Alfresco refers to Peer Associations simply as "Associations", but that's confusing. So the book will use the "Peer" distinction.) Peer Associations are just that—they define a relationship between two objects, but neither is subordinate to the other. Child Associations, on the other hand, are used when the target of the association (or child) should not exist when the source (or parent) goes away. This works like a cascaded delete in a relational database: Delete the parent and the child goes away.

An out of the box association that's easy to relate to is cm:contains. The cm:contains association defines a Child Association between folders (cm:folder) and all other objects (instances of sys:base or its child types). So, for example, a folder named Human Resources (an instance of cm:folder) would have a cm:contains association between itself and all of its immediate children. The children could be instances of custom types like Resume, Policy, or Performance Review. If you delete a folder, the folder's children are also deleted.

Another example might be a "Whitepaper" and its "Related Documents". Suppose that SomeCo publishes Whitepapers on its web site. The Whitepaper might be related to other documents such as product marketing materials or other research. If the relationship between the Whitepaper and its related documents is formalized, it can be shown in the user interface. To implement this, as part of the Whitepaper content type, you'd define a Peer Association. You could use sys:base as the target type to allow any piece of content in the repository to be associated with a Whitepaper, or you could restrict the association to a specific type. In this case, because it uses a Peer association, related documents don't get deleted when the Whitepaper gets deleted. You can imagine the headaches that would cause if that weren't the case!

上一章目录下一章