alfresco-devcon-header.png
When it comes to content modeling, the Alfresco Content Model works to enforce customer business logic and model consistency. Jan Vonka, member of the core repository team at Alfresco addressed these issues at the Alfresco Developers Conference NYC 2010.

Content Modeling

Good infrastructure requires good content management, but first you need consistent content. However, in order to effectively maintain consistency across systems and processes, the integrity of data is called into question and needs to be checked. Not only is this an actual component of Alfresco’s Content Model, it’s mostly true of most business strategies.

Let’s define a few things, first:

  • Modeling: something used an example to follow or imitate
  • Behavior: the way that something responds to a situation or stimulus

Inside the Alfresco Content Repository, you’ll find a storage engine, which engages storage of a potential arbitrary network of entity data. There are domains, nodes, stores, properties and association, all of which model different kinds of behaviors. 

Content models allow content to find their direction. Where does it go, how is it described, labeled, published and searched? What is its relationship to others? By building and designing models, content has not just a destination, but a specific journey outlined, as well. 

Using the following model components, developers can build dynamic or bootstrap content models accordingly:

  • Nodes: must be given a type when created.
  • Property: must be named, must be of a given datatype
  • Constraints: can hook in your own constraint implementation
  • Association: source node may be associated with zero or more target nodes

Certainly developers creating content models need not recreate the wheel each time. Alfresco offers 20-30 out of the box models. 

Designing and Managing Behaviors

Ultimately, your models are designed to dictate behaviors. And behaviors are defined by policies thato keep them in line. Behaviors can be bound by type or aspect and policies provide hook points to which you can bind behaviors to events based on class or association. By implementing a policy component, policies and behaviors can be managed so as to register policies, bind behaviors to policies or invoke general policies.

Like all behaviors, you can disable or enable as needed, as well as delete nodes, which may or may not get archived, depending on the model. When creating custom behaviors, words can be meaningful. If you delete a node, Vonak thinks you needn’t care whether it’s archived, as you shouldn't be relying on archive storage in the first place.

The connection between models and behaviors seems obvious enough, but by being able to check the integrity of each you can maintain consistency across systems, ensuring that what you want to happen is built to scale.