@dependency

Indicates that the cache state for a WCM-generated page has a dependency.

Dependencies play two important roles within Cloud CMS. First, they indicate to the runtime whether the previously cached output for a page may be used to service a future request ("requirements"). And second, they identify which data objects were used to build the page output ("produces"). This latter information is then be used to invalidate page objects when content items change within the Cloud CMS editorial environment.

As mentioned, there are two types of dependencies - requires and produces.

Requires means that the cached HTML can only be served if the requirement is met. The requires dependencies may only consist of request-time state that is known before the Dust processor begins to run. That way, the Dust processor can elect to use the cache state instead of executing the page. The requires dependencies are usually request information (url, parameters, locale) or user information (user's name, id) but may also consist of information that is acquired by Express middleware that runs ahead of WCM (which usually runs toward the end).

Produces means that the HTML output of the page contains data from one or more dependencies. These dependencies are identified by IDs and are usually Node IDs. If the page shows an attachment from a Node, it should be flagged as having a produces dependency with that Node's ID. If it shows article text in any way, the article's Node ID should be marked as a "produces" dependency.

If type is not specified, it is assumed to be produces.

For the most part, the Cloud CMS middleware will automatically take care of any requires dependencies. That said, if you write custom middleware for your Express app, you will need to account for any additional request-time state that you introduce and wish to key off of.

Parameters

• type
• key
• value

Result

The dependency is marked and execution continues.

Examples:

{@dependency key="{key}" value="{value}"}
    {+templateIdentifier/}
{/dependency}

{@dependency type="produces" key="{key}" value="{value}"}
    {+templateIdentifier/}
{/dependency}

{@dependency type="requires" key="{key}" value="{value}"}
    {+templateIdentifier/}
{/dependency}

Custom Middleware

Suppose that you have a web site where the HTML output that appears for a given URL is dependent on some externally looked up data, such as an account. You could write some middleware to load the account and store something onto the request (such as req._account).

Your Dust templates might then use this to render.

The first thing you'd want to do is make sure that your middleware informs WCM that the generated HTML is dependent on which account is being viewed. To do so, add the account ID into a page attribute like this:

req.pageAttributes["accountId"] = req._account.id;

And then mark the Dust output with a requires dependency, like this:

{@dependency type="requires" key="accountId" value="{request._account.id}"}

Now the HTML cached output will only be reused if the account IDs match.

You may also wish to signal that generated HTML is "showing" information from the account. You would do so like this:

{@dependency type="produces" key="accountId" value="{request._account.id}"}

With these two in place, it is possible for Cloud CMS to do two interesting things:

1. Cloud CMS can serve back cached pages for the correct account.
2. Cloud CMS can invalidate all cached pages which show information from a given account.

The latter is useful for scenarios where you ask the question: "If I change this account, what pages are impacted?"

Cloud CMS uses this capability from within the editorial environment for instant preview of content across all of the impacted pages of your web site.