Beginners guide to the ActiveView module

This week I decided it was past time to do a blog on the ActiveView product – WebReports' close sibling. ActiveView arrived a few years after WebReports and provided a way to integrate WebReports functionality into the Content Suite interface, allowing some pretty cool interface customizations without any OScript or WebLingo changes required.  

The first goal was to enable customers to provide new, modified views of container objects. However, ActiveView also offers several ways to tailor various menus within Content Suite such as Add Item menus, function menus, and top menus. 

The ActiveView module is currently only applicable to “classic mode” on Content Suite. However, some of the same technology is used to drive SmartView “Perspectives”. 

Note that for the remainder of this blog we will refer to the application of changes to the Content Suite UI as “overrides”. 

At its core, an ActiveView is a WebReport with a few minor differences (e.g. a reportview is called a template, and the default link is an EDIT command to name two variations). The real magic is in how the ActiveView can override parts of Content Suite defined by various criteria in the environment. There are five main features of the ActiveView module used to control when, where, and under what conditions an ActiveView is applied. These are (in order of precedence):

1. Override Type – Defines a particular category of override, ranging from types of containers to things like function menu overrides, property tabs, and others. Usually, this determines which kinds of Content Suite requests will trigger a given override. 

2. Request handler matching - This is a specialized type of override that can intercept nearly any kind of request. It is essentially a “catch-all” override type. 

3. Cascade Values – To control the scope of an override in the Content Suite system.

4. Priority settings – To manage which overrides take precedence when more than one override could take effect. 

5. Logic rules – Allows logical expressions to define whether a single ActiveView, or a number of different ActiveViews will be used. 

6. XML schema specifications within the ActiveView source - Some types of overrides use a predefined XML schema to specify some structured data changes. For example, changes to a function menu. Many of these types also allow some object filtering to be defined, such as object subtypes.

In this blog, we’ll describe some of the basics of these approaches, but a separate “deep dive” blog will explain the last three (more complex) features.

Scope

There are two significant distinctions in terms of ActiveView scope. 

Firstly, there are global ActiveViews that have a system-wide scope used for objects that do not have any context within a container hierarchy such as landing pages. These ActiveViews do not use a “Cascade Value”, and only the Global Overrides page can configure them under admin.index via “?func=activeview.GlobalOverrides”. 

Secondly, some overrides allow ActiveViews to be applied to some or all levels of a container hierarchy. You may configure the type of override to affect different parts of the hierarchy by accessing the “ActiveView” tab/property from an object’s function menu.

The main difference between these two overrides types is that the latter includes a “Cascade Value” field which effectively configures the scope of any ActiveView override.

The field called “Cascade Value” manages the Scope for an ActiveView. There are five settings described below. Developers who are familiar with the Appearances module may be familiar with a couple of these settings. However, some new ActiveView specific settings add some additional complexity to the cascade setting. The documentation doesn’t appear to have any detailed explanations of these, so hopefully, I can add some clarity here. 

Cascade Value

Cascading

The Cascading option is relatively simple. The override becomes relevant to that object and every single child object at every level below it when this setting is selected. 

Non-Cascading

The non-Cascading option is also relatively simple. The override becomes only relevant to that object and no others when this setting is selected for an override on a given object.

Cascade to Contents

This setting and the next two are less straightforward, but they address essential requirements. Cascade to Contents allows you to include a root container and all of the objects within it. You will find this useful for non-container objects. However, for any containers in the root, this scope applies to overrides like the function menu override. It does not apply to any browse overrides. In other words, a container below the root container will not have its container look and feel overridden. The keyword to understand this is “contents”.

Cascade to Level Below Only

This setting is very similar to the previous one, but there are two differences. Firstly the root container is not included in the scope. Secondly, any folder in the level below the root folder will also have its browse overridden. Possibly the easiest way to understand this is to look at a use case. For some customers, they may have a large set of folders for which they want to apply a particular override to their look and feel while they may not want this override applied to the parent folder. This specific setting allows you to apply an override to a group of folders without changing the folder they are contained in. 

Cascade to All Levels Below Only

This setting is similar to the previous one but will cascade to all levels below the root folder. Essentially similar to the Cascade option but it excludes the folder that has the override set on it.

Priority

The purpose of the priority setting is to allow some control over which override takes precedence if more than one override is in the scope of a particular object.  

Assuming that all overrides had the same priority, the natural priority is from the specific object up through the chain of parents. In other words, if an object has an override on it, that override will take priority over any cascading override from its parent or its parent’s parent. Similarly, the closest object in the hierarchy will always have precedence over any objects further up the chain. 

To modify this default behavior, you use Priority Settings.

Three of the priority levels (High, Medium and Low) are pretty self-explanatory. As a simple example, if you change the override on an object to low priority, and the parent object override has high priority, the parent object override would take precedence. You can manage most override scenarios in a hierarchy, using a combination of these three priorities to achieve your requirements. 

The remaining two priority levels are slightly more nuanced. The “Global” Priority setting is only available for global overrides. It is designed for scenarios where you want to apply an override system-wide, and you don’t want to override it by any other overrides that would typically have a higher priority. 

The final setting, confusingly called “Priority”, is designed as a remedy to the “Global” Priority setting. If you had created a Global override and given it “Global” priority, as mentioned above this override would have precedence over the whole system. Imagine then that you have one folder or a set of folders where you don’t want this global override to be used – for example, an Admin area or a management area. In this scenario, you use the “Priority” setting, which trumps everything. This setting is not available for global overrides. 

The basic strategy for managing a system is as follows:

• Use the same priority level for all of your overrides to start with. The default is High, but Medium is a good setting to use too. 
• When you have a scenario where you want to alter the standard rules of precedence, either raise or lower the priority for any of the overrides in question to achieve your requirements. 
• If you want to deploy a global override across the system universally, use the Global priority. 
• If you have a global override, but you want to bypass it for discrete parts of the system, use the “Priority” setting. 

Logic Rules

A powerful feature we introduced into ActiveView was the ability to create rules to determine one or more unique conditions that ultimately control whether a given ActiveView override is used.  

Using “logic rules”, you can define multiple ActiveViews for a given Override. With this approach, you can create different views for different conditions. 

For example, you could define different container views based on group membership. The expressions used to create these rules support the full set of WebReports tags and sub-tags in complex logic statements. This ability provides almost unlimited flexibility ranging from group membership, permission levels, device type, parameter settings, time of day, attribute values, and more - It is very powerful!  

If you’ve worked with the SmartView UI perspectives, this ability may seem familiar. That is because this part of the ActiveView processing engine was adopted and used to manage Perspectives logic. 

Typically, perspectives only use group membership and device type (as set through the Perspectives Manager. However, it is possible to edit Perspective “Logic Rules” from the Perspectives property tab for any container (or landing page) using the same syntax and capability of an ActiveView override. 

SmartView & Perspectives

As mentioned earlier, ActiveView is developed for the original (classic) view of Content Suite. Technically, ActiveView is not available on the SmartView interface. However, much of the functionality is available in Perspectives, particularly concerning enabling unique views (via widgets) on a conditional basis. We will probably write a more detailed blog about this topic in the future, but below we have a few points of interest.

Edit (2021/02/22) : starting with Content Server 20.2, a new Perspective object exists with an accompanying "Rules" object. This functionality can be used to replace the original ActiveView based paradigm; however, if you are using ActiveView "Expressions" beyond the more limited set of rules criteria in the new object, you will not be able to convert to the new objects as they currently exist.  The basic list of accepted rules conditions is: group membership, device type (mobiles etc.), and workspace types. This list is presumably growing so you need to consult the release notes for the most current version. 

The original Smart View Perspectives essentially use the same selection engine as ActiveView. This means that most of the conditional mechanisms defined above are also available for Perspectives, specifically:

• the Cascade Value (Scope)
• the Priority field
• the Logic Rules field

Typically, new users and developers will use the “Perspectives Manager” to define any conditions for the implementation of a given landing page or container view. This tool currently only supports the definition of logic rules to control a few popular conditions, such as group membership or device type. 

If you browse for a global Perspective (used for landing pages) or use the Perspectives tab for any container, you will see an almost identical interface to ActiveView. This interface will allow you to tweak things like the Cascade Value, Priority, and you could also create more complex conditions to control the use of a given view. 

Each Perspectives Override defined still uses an ActiveView object which contains a JSON declaration of the Perspective information (including Widget configuration). Typically these ActiveViews are created dynamically. 

One of the Widget types you can select (under Content Intelligence) is a WebReport. There are various types of WebReport widgets you can select (including pretty good documentation), so essentially, you can do many of the things that were possible in the past with ActiveView. Additionally, you can develop additional features and functionality through the SmartView SDK, including custom widgets, commands, toolbars, and menus. 

Unfortunately, Perspectives do not currently support any overrides to the various menus and function menus, and there are no current plans to adopt these features anytime soon.

Edit (2021/02/22): The new Perspectives Objects do not support the following:

• Cascade Values besides Non-Cascading and Cascading.
• The Priority field.
• Any expressions besides the ones identified in the current release notes. 

Summary

This overview covers a few basics of ActiveView and most of the pieces of functionality that are unique to ActiveView. That said, there are several admin settings and a few more complex areas that have not been covered here. We will do some deep dives in separate blogs, but ultimately we can create a customized training program for you.

To find out more, contact Ravenblack today and gain the experience only available through masters of WebReports.