Step-by-Step: Adding Aspects to the Content Model_Alfresco Developer Guide-QQ阅读女生青春网

上QQ阅读APP看书，第一时间看更新

Step-by-Step: Adding Aspects to the Content Model

SomeCo wants to track the client name and, optionally, the project name for pieces of client-related content. But any piece of content in the repository might be client-related. Proposals and Status Reports are both project-related, but the two will be in different parts of the model (one is a type of legal document while the other is a type of operations document). Whether a piece of content is client-related or not, it transcends department—almost anything can be client-related. The grouping of properties that need to be tracked for content that is client-related is called an aspect.

Here's another example. SomeCo would like to selectively pull content from the repository to show on its web site. Again, any piece of content could be published on the site. So an indication of whether or not a piece of content is "webable" should be captured in an aspect. Specifically, content that needs to be shown on the web site needs to have a flag that indicates the content is "active" and a date when the content was set to active. These will be the aspect's properties.

Let's modify the content model to include these two aspects. To add the client-related and webable aspects to the content model, follow these steps:

Edit the scModel.xml file.

Add a new aspects element below the types element to contain the new aspects. Add one aspect element to define the client-related aspect and another to define the web-related aspect. You'll notice that the syntax for the aspect element is identical to the type element:

    <aspects>
      <aspect name="sc:webable">
       <title>Someco Webable</title>
       <properties>
        <property name="sc:published">
         <type>d:date</type>
        </property>
        <property name="sc:isActive">
         <type>d:boolean</type>
         <default>false</default>
        </property>
       </properties>
      </aspect>
      <aspect name="sc:clientRelated">
       <title>Someco Client Metadata</title>
       <properties>
        <property name="sc:clientName">
         <type>d:text</type>
         <mandatory>true</mandatory>
        </property>    
         <property name="sc:projectName">
         <type>d:text</type>
         <mandatory>false</mandatory>
        </property>
       </properties>
      </aspect>
    </aspects>

Save the model file.
Run ant deploy and restart Tomcat.

Alfresco should start cleanly without making any model-related complaints.

Aspects

To appreciate aspects, first consider how inheritance works and its implications on the content model. Suppose that SomeCo only wants to display a subset of the repository's content on the web site. (In fact, this is the case. The SomeCo write-up in Chapter 1 said that, except for job postings, HR content shouldn't go near the public web.) In the recent example, webable content needs to have a flag that indicates whether or not it is "active", and a date that indicates when it became active.

Without aspects, there would only be two options to model these properties. The first option would be to put the properties on sc:doc, the root object. All child content types would inherit from this root type, thus making the properties available everywhere. The second option would be to individually define the two properties only in the content types that will be published to the portal.

Neither of these is a great option. In the first option, there would be properties in each and every piece of content in the repository that may or may not ultimately be used. This can lead to performance and maintenance problems. The second option too isn't much better for several reasons. First, it assumes that the content types to be published to the portal are known when you design the model. Second, it opens up the possibility that the same type of metadata might get defined differently across content types. Third, it doesn't provide an easy way to encapsulate behavior or business logic that might be tied to the published date. Finally, property names must be unique across the model. So you'd have to modify the names of the properties in every type in which they were used, otherwise it would be a serious pain later when you try to run queries across types.

As you already know, the best option is to use aspects. Aspects allow "cross-cutting" of the content model with properties and associations by attaching them to content types (or even specific instances of content at runtime rather than design time) when and where they are needed.

In this case, SomeCo's webable aspect will be added to any piece of content that needs to be displayed on the web site, regardless of type.

Another nice thing about aspects is that they give you a way to have multiple inheritances. As you saw in the model, types can only inherit from a single parent. But you can add as many aspects to a type or object instance as you need.