Behaviors

Cloud CMS lets you wire in behaviors behind your content models so that rules automatically execute when your content is touched. Content editors work with simple forms to create content that conforms to your defined content models. When that content is created, updated or deleted, it automatically triggers policies (or events) which you use to bind in custom behaviors.

In this way, the developers can wire up behaviors and the editorial team never needs to know about it. Furthermore, behaviors are wired in behind the content model, so they execute no matter how people interact with content. If they interact with content via the API, via WebDAV, via FTP or via the User Interface, it doesn't matter. It's all the same thing.

This provides you with a consistent and universal way to define your content models that the usage of that content across the entire enterprise.

Behaviors

In Cloud CMS, a behavior is either a Rule or a Script.

A Rule is a configuration-driven command such as "Call out to a Web Hook" or "Send an Email". It accepts a JSON configuration and then does its thing. Rules are also conditional - you can set up conditional logic that must be true in order for the rule to run. For example, you can say "Call out to a Web Hook only if the property state is equal to published".

In Cloud CMS, you define Rules using the Rule Wizard.

A Script is a bit of JavaScript that you code by hand. It sits inside of Cloud CMS and is then executed when the policy is triggered. Unlike Rules, Scripts do not allow for wizard and configuration-based management of conditions and actions. Rather, Scripts are simply code - you write them and do anything you want inside of them.

Both Rules and Scripts are really just standalone content nodes. They can be of any type you like but must be tagged with the f:behavior feature. This signals to Cloud CMS that the node contains a behavior implementation.

Binding Behaviors

As mentioned, behaviors are standalone nodes. To wire a behavior to another node, you use an association of type a:has_behavior. The a:has_behavior association points from the node to the behavior. It is in effect saying "I am a node and I have this behavior".

The a:has_behavior association connects to either a Content Instance or a Content Type.

When a behavior is bound to a Content Instance, the behavior only triggers for that one content item. When the behavior is bound to a Content Type, the behavior will trigger for ALL instances of that content type.

The a:has_behavior association should therefore be created from either:

• A Content Instance node
• A Content Type node

And it should point to either:

• A Rule Node
• A Script Node

An a:has_behavior association should also have the following two properties:

• policy - the QName of the policy, such as p:beforeCreateNode
• scope - either 0 (for instance binding) or 1 (for type binding)

By default, policy bindings are scoped to all properties. If you would like to scope to a specific property (and if your policy provides for it), you will need to set the following property on the association:

• property - the name of the property to bind to

Save your association. Cloud CMS will automatically re-compile the policies for your branch. For all subsequent operations against the branch, the policy system will trigger your behavior.

Policies

Every behavior binding needs to define a policy that it binds to. A policy is essentially an "event type". It tells Cloud CMS what kind of event needs to be raised in order for the behavior to trigger.

For example, you might bind a Rule that executes against a Node "when the node is updated". The policy for "when the node is updated" is called "p:afterUpdateNode".

Policies can bind to events that affect the entire node or properties of a node.

Cloud CMS offers a wide array of policies for nodes, associations, properties, binary attachments, data lists and more. For a full list of policies, see Policies.