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 typea: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:beforeCreateNodescope
- 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.