Rethinking smartUI Part 4-B

Forms Rest command

Some weeks ago I published a new video on Rethinking smartUI on Youtube. Now we have Rethinking smartUI Part 4-B discussing the main part of gathering and displaying thr documents data.

If you havn’t it seen yet, here is the short video. In this posts, we’ll go though the technical aspects of this new kind of approach to smartUI. This demo is a Document Pad (or short DocPad), displaying all document properties in a SCIFI GUI arrangement.

A warning at the beginning: To use this code with IE11 is a perfect way to test all js error messages. Use this code only with the newest browsers. Its tested with Chrome (V98), Chrome Canary (V98), FF Developer (95.0b4), Edge (95.0) and Firefox (93.0)

The other parts of this post were

Part 4-A The Javascript Part 1

Part 3 The Infrastructure and the CSS

Part 2 The HTML

Part 1 Overview

In the part 4A, we had discussed all the js responsible for the perimeter of the whdgetz. Not lets discuss the main part which is responsible to gather and displad this data:


A CSS Grid

As you can see, there are 6 panels arranged in a CSS grid.

For infos on the css, please review this post, the part 3 of this series.

So let’s start with the panel at top left.

The documents metadata

This is more or less the data which is related directly to the document. The documents node number was the output from the node picker . The nodepicker was closed by the done() callback.


Here we are in the this function of the nodepicker. We extract the node from the callbacks arguments an get the id with the topmost arrow. We extract the name of the node and put this name inside the id #document.

The loadDescriptions function does the work.


The prelude is simply to select the first face “”


If this is not undefined (remember, smartUI always makes 2 runs, so its always a goot idea to test if its defined) the create and modify dates are extracted and translated in a standard js data. For non-US readers it will be always a difference between p.ex 04-05-20 and 4.Mai 2020 (US and german dates for the Star Wars day May the fourth), thats why we translate the dates.

Also we need to get the users of the creation and the modification. But these are numbers, so we want to translate them to names.

Next, extract the server from the connection and construct the members REST command to get these names.

First view: The fetch command

fetch is new in js 6. In this older, antique times you would have used some ajax variants like xmlhttprequest or some similar methods which we will use in other calls for comparism.

Fetch command

Technically, we have to issue two REST calls to /member/ to get the names of the createuser and the modifyuser. We use the fetch command.

Remark: the famous async/await would be much more handy for that, but we wanted to limit the language scope to js6 for these posts.

Once we get the responses, we’ll put that names simply as innerHTML on the panel.

Technically, you can use all other avaliable methods to put text on the panel, from template-strings to create a and fill a text nodein the DOM. You can even invite handlebars to do this for you.


In the top middle panel we added the document thumbnail, which is created automatically during indexing on the server.


We must enter the nodeid in the REST command /thumbnails/medium/content to get the medium resolution version of the thumbnail.

To show the diffence to the fetch comand, the old archaic XMLHttpRequest was used.

The receiving image is put into a div with the id “Thumbnail”.

Image Correction

In the case the user selects another document the old thumbnail would remain. So we remove the old image element.

Almost done, we need to put our otcsticket in the request header and to send the request to the server.


In this function, we use exactly one REST call to get all data at once. This is done by the function /forms/update?id=xx whick will deliver all data for that nodeid at once. Expecially the categories take a while, so a css-fog was used to cloak the image of the approaching grid until the data was received (revisit the video). Then the css fog is cleared and trhe categories are displayed.

The call is also done with the old XMLHttpRequest to show the diffences to the modern fetch command.

Local functions were used instead of those in “this” to keep the scope clean.


The categories and the attributes


Categories were returned in an object with their category name a title in the entry. To get the attributes we have to do a little bit more.


We split the result into several arrays to extract the values. If we have “date” in the type field, we have to use our date translation also on that to display the dates correct.

Security Clearances

All security related data is on the fouth face, the one on the lower left.

Security Clearances

Here, all security levels and markings were displayed inside a span.

Records Management Data

here we extract and fill the data on the lower middle panel.

Records Management

The Versions Data

Here, the REST commend has a problem. Versions are not included in the answer of the REST command, at least in the Content Server versions 21.3 and 21.4. So let’s ionform the user on this fact and display a local language string of this fact.

Tip: Maybe there will be a patch to fix this in the near future.

Versions Data

So we had all parts discussed.

We offer a one day remote training to understand the javascript code. If you are already a sophisticated Javascript Developer, you can get the free Sources also from (a public repository on Github).

Warning: This is only the sourcetree of the project, so you have to insert this in your own project file.

The data returned from the formsupdate?id=nn REST command

The whole data structure is send back in response to a forms/update?id=nnn REST call. Some of these entries take quite a while, so try using some css to cache this.

Forms Rest command

Have fun on discovering the endless possibilities of Dashboards and other Contentserver smartUI extensions using javascript6 and css3.

The sky is the limit.

Rethinking smartUI Part 4-A

Rethinking smartUI

Three weeks ago I published a new video on Rethinking smartUI on Youtube. Now we have Rethinking smartUI Part 4-A discussing Javascript. If you havn’t it seen yet, here is the short video. In this posts, we’ll go though the technical aspects of this new kind of approach to smartUI. This demo is a Document Pad (or short DocPad), displaying all document properties in a SCIFI GUI arrangement.

This is Part 4-A of a multipart post covering Javascript of DocPad. For the css refer to part 3 of Rethinking smartUI.

Warning: This is a lot of js code, so I subdivided this Part 4 into Part 4-A and 4-B (getting all documents infos with 1 Rest call). Part 4-B will be published next week.

We offer a one day remote training to understand the javascript code. If you are already a sophisticated Javascript Developer, you can get the Sources also from (a public repository on Github).

Warning: This is only the sourcetree of the project, so you have to insert this in your own project file.

The post parts until now

Part 4-A The Javascript Part 1

Part 3 The Infrastructure and the CSS

Part 2 The HTML

Part 1 Overview

But first to Rethinking smartUI Part 4-A.

The Javascript auxiliary files

Using the model factory

The idea of a model factory is to combine several functions in one.

a. Create a model and return it.

b. Load server data into this model for use in the main constructor function

A typical factory looks like this:

// the factory for the model
‘csui/utils/contexts/factories/factory’, // Factory base to inherit from
‘csui/utils/contexts/factories/connector’, // Factory for the server connector
‘ademo/widgets/docpad/impl/docpad.model’ // Model to create the factory for
], function (ModelFactory, ConnectorFactory, DocpadModel) {

‘use strict’;
var DocpadModelFactory = ModelFactory.extend({
propertyPrefix: ‘docpad’,
constructor: function DocpadModelFactory(context, options) {
ModelFactory.prototype.constructor.apply(this, arguments);
var connector = context.getObject(ConnectorFactory, options);
// Expose the model instance in the property key on this factory instance to be // used by the context = new DocpadModel(undefined, {connector: connector});
fetch: function (options) {
return DocpadModelFactory;

The main Javascript files

The lang.js file(s)

The language system consists of those strings which are pupposed to change per language.

helloMessage: ‘Hello {0} {1}!’,
waitMessage: ‘Please wait’,
seldoc: ‘Select a Document’,
printdoc: ‘Print the selected Document’,
pickerTitle: ‘Select a Document’,
selectPickerButtonLabel: ‘Select’,
descNodeID: ‘Node-ID’,
desDescription: ‘Description’,
desCreated: ‘Created’,
desModified: ‘Modified’,
……more …..

The standard model from Backbone.js

], function (Backbone, Url) {
‘use strict’;

let DocpadModel = Backbone.Model.extend({
defaults: {
name: ‘Unnamed’

constructor: function DocpadModel(attributes, options) {
Backbone.Model.prototype.constructor.apply(this, arguments);

// Enable this model for communication with the CS REST API
if (options && options.connector) {
// Computes the REST API URL using the connection options
// /auth returns information about the authenticated user
// usage of => not possible because of “this” is used for urls
url: function () {
return Url.combine(this.connector.connection.url, ‘/auth’);
} ,

parse: (response) =>


return DocpadModel;



Remark: The Arrow Function at parse is pure js6. But let me quote here

An arrow function expression is a compact alternative to a traditional function expression, but is limited and can’t be used in all situations.

Differences & Limitations:


This means, its not possibe to use when any limitation will take place, like in the constructor.

The docpad.view.js

The stages of docpad.view.js

Get infos via the Bootstrap model

constructor: function DocpadView(options) {
options.model = options.context.getModel(DocpadModelFactory);, options);
this.listenTo(this.model, ‘change’, this.render);

First, we initiate the model (and read the data) via a standard model using the model factory. Then we call the constructor in the prototype with the cs options. Lastly we listen to a change of the data and (in case) we rerender the widget.

Load the photo

The user data contains (eventually) a photo of the user. This is loaded and inserted in the DOM with the function loadPhoto. Here the js6+ fetch function is exposed to get the photo and insert it into after the element woth the .photo class in the dom.

loadPhoto: function () {
let server = this.model.connector.connection.url;
server = server.substr(0,“api/v1”));
let url = server + this.photo_url;
let ticket = this.model.connector.connection.session.ticket;
fetch(url, {method: ‘GET’, headers: {“OTCSTicket”: ticket}})
.then(response => response.blob())
.then(function (myBlob) {
const URL = window.URL || window.webkitURL;
let photo = URL.createObjectURL(myBlob);
let img = document.createElement(“img”);
img.src = photo;
setTimeout(() => {
}, 100); // cleanup

Using the Node-Picker

The Node-Picker is a standard function in the sdk, so we use it.

The file ‘csui/dialogs/node.picker/node.picker’, // the csui node picker

is required at the beginning of the docpad.view.js file under the local name of NodePicker like this:

‘csui/lib/underscore’, // Cross-browser utility belt
‘csui/lib/marionette’, // Marionetter
‘csui/lib/moment’, // the date/time lib in csui
‘ademo/widgets/docpad/impl/docpad.model.factory’, // Factory for the data model
‘csui/dialogs/node.picker/node.picker’, // the csui node picker
‘i18n!ademo/widgets/docpad/impl/nls/lang’, // Use localizable texts
‘hbs!ademo/widgets/docpad/impl/docpad’, // Template to render the HTML
‘css!ademo/widgets/docpad/impl/base’, // base Stylesheet needed for this view
‘css!ademo/widgets/docpad/impl/adv’, // adv stylesheet for this app
‘css!ademo/widgets/docpad/impl/print’ // print style sheet
], function ( _, Marionette, Moment, DocpadModelFactory, NodePicker, lang, template)

The picker is started by pressing the big button, this actually calls showThePicker. Types of 144 (only Documents) and on the enterprise volume are among the start conditions.

The title and other strings are extacted from the appropriate lang.js language file(s). The command at the beginn of the chain displays the nodePicker

showThePicker: function () {
if (undefined === this) {
let btn = document.querySelector(“.btn”);

let nodePicker = new NodePicker({
connector: this.model.connector,
selectableTypes: [144],
dialogTitle: lang.pickerTitle,
selectButtonLabel: lang.selectPickerButtonLabel,
startLocation: ‘enterprise.volume’
nodePicker.s how()
.fail(function () {
console.error(“Picker fails to show”);
.done(_.bind(function (args) {
.replace(“hide”, “display”);
let node = args.nodes[0];
let id =;
this.docname =;
document.querySelector(“#document1”).innerHTML = this.docname;
this.loadDocumentThumbnail(id); // load the thumbnail and display it
this.loadDescriptions(node); // load node data and display it
this.loadNodeData(id); // inquire form update data and display it
}, this)


The callback in the .done clause simply extracts the node id and the name from the results and stores them in the docpad “this”.

In the next week part “Rethinking smartUI Part 4-B” we’ll discuss the REST Commad how to get all document data (nearly) at once.

Rethinking smartUI Part 3

The upper PART

Two weeks ago I published a new video on Rethinking smartUI on Youtube. If you havn’t it seen yet, here is the short video. In this posts, we’ll go though the technical aspects of this new kind of approach to smartUI. This demo is a Document Pad (or short DocPad), displaying all document properties in a SCIFI GUI arrangement.

This is Part 3 of a multipart post covering the technical start of DocPad and the associated CSS

The post parts until now

Part 4-A The Javascript Part 1

Part 3 The Infrastructure and the CSS

Part 2 The HTML

Part 1 Overview

A. The technical infrastructure

Die DocPad is started via the index.html, found in the test folder of the docpad. This is because of its much easier to test modifications via index.html compared to installing the finished widget in the content server and trying it then.

The first part of index.html

The first part of index html

The whole page is more or less standard. We habe 4 areas of interest in the first part. Dont forget, nuc was introduced in 21.2. In older versions nuc was not existant.

  • A. Here, you see the config is moved to the nuc area
  • B. Change A will also require to add the nuc-extensions to the list of dependancies for csui. Thed whole js code is loaded by the “ademo” extension.
  • C. My machine is on a VM. This means, if you put this on your machine, you’ll have to enter your url and your support directory (called supportPath) in the configuration.
  • D. I’ve used my ticket to provide the login. You can use username and password to login the more convential way or also provide a ticket of youfself here. The displayed ticket won’t work at your site.

The second part of index.html

Part 2 of index html

Here we have this points of interest

  • A. The require parts of needed modules. It is a docpad.mock.js in the list of modules, but its not recommended to use the mockup facility because there is lot of traffic from and to the server. Its much easier to add a real content server behind that index.html.
  • B. Standard procedure. Instanciate the widget with the context, display it in the region and fetch the context from the server. As mentioned, its easiere to use a real server as data source so switch the mockup off.
  • C. The marionette region is associated with the id=”widget” of this div, so the widget is displayed here.

At the end there is immediate function starting with

(function() {
var ws = new WebSocket('ws://' + + '/jb-server-page?reloadServiceClientId=1');

This is inserted by Webstorm (my JS IDE) to allow auto-reload of changed files. You can ignore that, other IDEs will solve that differently.

B. The CSS


Here, all css files used in the docpad are listed in the require.js list of required modules. For demo purposed and to keep things simple, I used 3 css files:


This file contains the basic css instructions to style the .hbd template shown at the top of list.


contains the more advanced css instructions for docpad


is the print style sheet to provide a proper output on paper.

Disclaimer: The css instructions selected do not impose or propose any styles to be followed, instead they are used for pure demo purposes here.

The base.css File

Here the main functionality of the css is found. One of the feature of css3, the variables, is used. In the pseudo element :root all variables used in different rules are defined.

css setup

At the end of the snipped you’ll see a media query, saying the following is used tor screen display.

Lets discuss several stages:

The header + the footer


These two structures exploit the standard userinfo with REST from the content server in a standard backbone model. “Hello xxxxxx” is a structure from the hello world demo with the word “hello” and the signed in user. The photo is downloaded from the content server and dosplayed.

The bottom structure simply prints out other user data on the screen .

Points of interest:

Font used

The nice digital effect is build with the font “digital-7”

The header is done with

The header

Ther photo is inserted at the position of the .photo class in the size of 80×60 pixel. Then the photo gets this nioce rounded look using border-radius.

the footer conststs of three divs, which are positioned in 3 columns

The footer

The divs have the classes .boxcell and .leftbox and are descendants of the .footerbox

The document display

The document display consists of six divs and are positioned using a css grid.


They have numbers, the numbers range from one (“card1”) to 6 (“card6”). The css part is (shown here only a fraction):


They are all children of the cube, using the display mode grid and displaying the 6 cards in two rows and threee columns.


Using the diffent REST methods in the js code, these cards were filled by the standard methods of DOM interaction from js. This will be the main theme of next weeks post, the js code of “Rethinking smartUI” Part 3.

Rethinking smartUI Part 2

Last week I published a new video on Rethinking smartUI on Youtube. If you havnt seen yet, here is the short video. In this posts, we’ll go though the technical aspects of this new kind of approach to smartUI. This demo is a Document Pad (or short DocPad), displaying all document properties in a SCIFI GUI arrangement.

This is Part 2 of a multipart post covering all aspects of this Docpad.

The post parts until now

Part 4-A The Javascript Part 1

Part 3 The Infrastructure and the CSS

Part 2 The HTML

Part 1 Overview

The html

First, lets take a look on the html (in out case the .hbs file). This is the top part of the widget,

The HBS file, Part 1

The div with the class “topbox” contains the Username and the Photo. There is also a Print-Button, if a document is selected.

A button, class “picker” is sorted in a div with “picker”. This is the button used to start the node picker component. Its hidden now, will be used later, when a document is selected.

The documents data is displayed using a cube. A cube has six sides so all sides can be presented using a css grid or …. (arranged in a 3D cube which can be rotated in 3D. But thhis is not part of this demo).

The whole thing is arranged in a div with the id of “content”. The top element is a div with the class “cube”, holding six divs for the six sides

The html of the cude

Just for fun, the cube is surrounded by a div with the class “cam”. If you want to display the cube as 3d cube. This is used to set the perspective on a 3d Cube. If you are interested in learning more on 3D css cubes, refer to

Lets see the Actions.

The Actions in Detail

After starting the aplication, there are several stages, They are

a. Application started

Docpad started
Docpad started

Here, the application is just started. the “Select a document” started from the top left and moved in the center of the window. This button will initiate the nodepicker, a standard component of the smartUI library.

Until now, we queried the user logged in. Then, we greet the user, extract the photo from the Content Server Database and display this photo in the top right. To make it more interesting, we displayed the photo in round form via css.

In the three panels at the bottom we displayed the rest of the user record. Just for fun we surrounded the three botton panels with a border animation.

b. Nodepicker selected

The next stage is the nodepicker. After pressing the “Select a document” button, it is started and delivers a list folders and documents on the associated Content Server. Meanwhile, the Button moved again back to upper left corner.

c. Document selected

After the user selects a document, all data of this document is read from the server. In this case, the “APAC Expense Report.xlsx” is selected. (Refer to part 1 to see which REST commmands are used).

As of do have a document, we can display the header and the print button.

As you can see when playing the video, the cube starts in some distance and is a little but foggy during the approach and clears when we receive all data.

Display of the document

The reason is, that the forms/update REST call takes longer and we use CSS animations ans css view filters to hide that fact from the user. When in doubt, view the video on top of this post again.

For beauty there are also some hovering effects added, on the panels and on the thumbnail.

d.Document to Print

The last stage is (besides selecting a new document to display) is to print the document.

Here we have the print previev in Chrome

Print stylesheet in action

As we can see. the node data is printed in the form of a css grid on paper. The display is in standard layout. A media query selects a print style sheet instead of the normal stylesheet(s).

In the next week we discuss in Part 3 the index.html to start the widget standalone and css stylesheets (there are really several). We’ll then conclude this series in Part 4 discussing the Javascript made for this demo.

We’ll use the 4 steps of the application as the schema for Part 3 and 4.

See you next week!

The new smartUI Nuc. A closer look.

The new NUC package in smartUI

Disclaimer: The discussed topic is on Content Server 21.2 smartUI SDK and may change anytime without notice after today (I dont hope so, but….)

The new package nuc in the smartUI SDK is the

(quote) nucleus of the nucleus (endquote)

and something like “the Best of the best, Sir” (Men in Black I)

What is nuc?

Lets take a look at the lib/src folder in an initialized 21.2 project. To see the images larger, right click and open the image in a new tab.

Nuc, The Nucleus of the Nucleus

The nuc consists of these folders:


This folder was located in the csui package in ancient time. Nowadays it has moved to nuc.

If you compare that to the csui/utils(21.1), you’ll discover a few differences

And also csui/utils(21.2)

If you use requirejs paths to elements, which are not in csui/utils(21.2), you should check these references and edit them to point to the proper element if needed.


This folder was located in the csui package in ancient time. Nowadays it has moved to nuc.

If you compare this with the csui/models(21.1), you’ll notice a few differences.

And also compared to the csui/models(21.2) there are differences:

A closer look reveals, that the csui/models(21.2) is not identical to csui/models(21.1) and therefore you are supposed to correct manually any requirejs paths in your js code, if you have to require those models moved from csui/models to nuc/models.


This folder was located in the csui package in ancient time. Nowadays it has moved to nuc. The folder contains

If you compare that with lib at csui (21.1) and also with that lib folder existing in the csui (21.2), you’ll discover, that csui/lib(21.1) is the same as csui/lib(21.2), whereas nuc contains a subset of the entries of 21.1. At least on 21.2 the csui/lib references seem to work perfect, so that those in nuc/lib could be ignored.


This folder was located in the csui package in ancient time. Nowadays it has moved to nuc. It contains that:

If you compare that with the grunt-tasks at 21.1, you’ll discover a surprisingly large amount of additional documentation files. The old 21.1 csui/grunt-tasks had only the, whereas there are a lot of additional md’s on 21.2 nuc/grunt-tasks available.


this is a new folder consisting of a couple of pre-defined bundles. These Defines([]) are quite handy to use. Nothing special here.

Amending the tabbed perspective

Tabs in the header: Playing hide&seek

In the tabbed perspective there is a nice game of hide and seek implemented. This gives you excellent entertainment, but you can amend this to simply display tabs as usually in any non-gaming environment. All examples here are displayed using the index.html from the /lib/src/csui/perspectives/tabbed.text/index.html. (Version 21.1)

The described way tabbed perspectives behave in smartUI is not a bug, its a feature.

The initial game

It goes like this:

The not so hidden hide&seek tab mode

If you have defined a header and several tabs, filled with standard data, you’ll see this initially. But when you click on any but the first header, the game is activated.

Hide&seek mode activated

A simple click on the tab name activates the hide &seek mode. The tabs try to hide and you are supposed to seek for them. This is really a nice and entertaining game.

The conservative Amendment

But what if you want to switch off this challenging mode?

Deactivating the hide&seek mode to allow the more conservative tab display

The build in hide&seek mode can be switched off by commenting this two lines in the tabbed.perspective.view.js.

A reload of the test page gives you by clicking to the second or thirth tab this:

The converwative Tab Display.

Although you switched of the hide&seek mode, you can now use the SDK to display the tabs in a more conservative way.

The smartUI SDK is very versatile and can be used for several purposes, even for conservative tab displays.

The only thing to decide for you is how to change that in the smartUI. Either spawn this into your own perspective or map your changed .js file over the standard requirejs path, this is up to you. You can even try to clear the cs-collapse.css and cs-toggling.css classes using the csui-stype-override-kit (I have not tested that for side-effects).

Happy tabbing.

New in Content Server 21.1: New Webreport Widgets and Extensions


There is already an amazing set of webreport related widgets in the smartui (like HTML Webreport, Nodes List WebReport, Visual Count and Widget Carousel) in smartUI along with a couple of controls, models and actions which make the usage of webreports in smartUI much easier (like parameter.prompt.form,, status.screen, open.webreport, WRTextModel etc). More detailled informations can be found in my Training “Advanced Workshop Webreports”.
At the dawn of the new version, we got a couple of new and extended widgets to be used with webreports.

Some amazing new full-page widgets hit the road

New in Content Server 21.1: New Webreport Widgets and Extensions. They display a full-page of data in a folder or Business Workspace in the Smart View. Three new full-page Content Intelligence widgets are now available to use with Perspectives:

  • Nodes Table Report – Full page
  • Table WebReport – Full page
  • Visual Count – Full page

Users may want to display visual countable data as a full-page chart or present a list of nodes, for example documents to be processed, in a full-page format in the Smart View.
The new full-page widgets will also work with Business Workspace tabbed perspectives, to add various reports sourced using WebReports. Full-page widgets can also be used with other Perspective layouts.

New Webreport Destination

A new WebReport destination, Full Page Widget, sees action for the Nodes Table WebReport, Table WebReport, HTML WebReport and Visual Count destinations.
Once the Full Page Widget output destination is selected, the Nodes Table WebReport, Table WebReport, HTML WebReport or Visual Count can be selected for the Type.
To support the new transport destination added for full page widgets, the transport destination page now has references to the Table Report SubWebReport node and the Visual Count button node to be transported.

Nodes Table WebReport – full page

The Nodes List WebReport widget displays a list of items (nodes) generated from the WebReport’s data source in a full-page view, similar to the browse view.
Parameter prompts can be added for the user to input date ranges, attribute values, etc. using the commands, actions and models mentioned above (since 20.1). If in use, an edit pencil button will display to edit the parameters.
Custom columns, scrolling, name search and pagination are supported.
The node action menu and multi-select actions are available to work with the items in the result set.
All titles and labels support multilingual metadata.

Configuration is done this way. Configure thhis widget and add the title and the node id of the webreport to display in the perspective manager. An Icon Class displays the appropriate Icon on the widget.

Table Web Report – full page

The Table WebReport widget displays a list of items based on the WebReports data source in full page mode.
Parameter prompts can be added for the user to input date ranges, attribute values, etc. using the commands, actions and models mentioned above (since 20.1). An edit pencil button will display to edit the parameters.
Additional data columns, scrolling, column filtering for multiple columns and pagination are supported.
Additional actions can be added, for example a sub-WebReport to initiate a workflow, send an email or create a document node from the item.
Titles and labels support multilingual metadata.

Visual Count – full page

The Visual Count helps visualize countable data using a full-page chart in the Smart View. The chart view (can use bar, donut or pie) has controls for users to filter and drill into data easily.
Parameter prompts can be added for the user to input date ranges, attribute values, etc. using the commands, actions and models mentioned above (since 20.1). If in use, an edit pencil button will display to edit the parameters.
Action buttons can be added, such as export to CSV file, email report data and initiate workflow.
Titles and labels support multilingual metadata.
The Visual Count tile widget and full-page Visual Count widget has a new Horizontal Bar type option.
The original Bar type has been renamed to Vertical Bar to distinguish the two bar types.
The horizontal bar, vertical bar, donut and pie chart types can be changed in the Perspective Manager and Edit page.

New WebReport features

New Enable Row Filters Tag

This new tag [LL_WEBREPORT_ENABLEROWFILTERS /] is designed to automatically filter a WebReport data source when the report is used as a button with the Visual Count widget.
This has also been added to the tag guide as a general feature. This allows WebReports to have better out- of-the box support for dynamic complex filters.

Hidden columns allowed to be included in Table WebReport widget

A new tag option is now available for Table WebReport widgets, INCLUDEHIDDENCOLUMNS:, to specify a list of columns that you want to include in the data returned to the client for each data row. The column will not be included in the columns array in the response.

New in 21.1: Multilingual Metadata Support

Multilingual Metadata in 21.1

Finally, Multilingual Metadata Support is implemented in Content Server 21.1. Before that version there was only Support available here.

The Users Point of Vue

Multilingual Metadata can be added/edited at the Property Panel of a document. The first screenshot gives the entry of the name, the second gives the entry of the Description field.

Multilingual Metadata in 21.1
Multilingual Metadata in 21.1

Only Names and Descriptions are supported for Multilingual Metadata. For more fields or even Category Attributes in multiple languages, refer to an OpenText Partner like CASSIA.

The Programmers Point of Vue

The Name and Description fields show at least two multilingual text pickers. These are found in the SDK in /lib/csui/controls/multilingual.text.picker and in /lib/csui/dialogs/multilingual.text.picker. Unfortunately there is no Documentation and no index.html. Lets take a look on that control:

The Controls

The left screenshot is from dialogs, the right is from controls.

Multilingual Text PIcker

This is embedded in the header.view.js from the dialogs/node.picker and will only be activated, if Metadata Languages are enabled. The mixin allows the form to be displayed as a Bootstrap Popover.

Mixin Start

Changes in that area require the changed multilingu<al text picker and also the changed paths to be followed for that changes. Therefore require a spawn of the whole nodestable widget to reflect that changes. This is acually not recommended.

Happy MLM

The new Treebrowse Component – Nearly a Windows Explorer

Treeview Control

The Treebrowse Component is a new in Content Server 21.1. What’s a Treebrowse?

Let’s take a look at the index.html at csui/controls/treebrowse/test

Treeview Control

This is an additional Window with the tree based display of all folders in a Content Server. It can be configured that a click on the top left icon will switch it on and off. This Treebrowse Control will then change the display of a Nodestable according to the folder pressed.

Additional Features

Lazy loading and prefetch options for performance. There are a couple of options to configure the loading of the nodes for performance. A “Show More” button can be configured

Tree Navigation is in sync with Table View in Nodestable view. The Nodestable is displays the children of the selected folder.

Multiple root nodes can be configured.


This Treebrowse is always there, but it must be enabled.

'csui/lib/backbone', "csui-ext!csui/controls/treebrowse/navigation.tree"
], function (module, Backbone, moduleConfigs) {
'use strict';
var config = module.config(),
enableSystemLevel = !!config.enable;
moduleConfigs = moduleConfigs || [];
var configModel = Backbone.Model.extend({
defaults: {
sequence: 100,
enabled: function (status, options) {
return false;
data: function (status, options) {
return {};
configCollection = Backbone.Collection.extend({
model: configModel,
comparator: 'sequence'

The var enableSystemLevel is interesting.

var NavigationTree = {
enabled: function (status, options) {
  if (!!enableSystemLevel) {
    return true;
  var enabled                = false,
      moduleConfigCollection = new configCollection(moduleConfigs);
  moduleConfigCollection.some(function (mConfig) {
    enabled = mConfig.get('enabled')(status, options);
    if (enabled) {
      status.originatingView.treeData = mConfig.get('data')(status, options);
    enabled = enabled ? true : enabled;
    return enabled;
  return enabled;
return NavigationTree;

As you can see, the Enablement on a system level can be done in OScript. Refer to this post, if you want so figure out how.

If you want to configure this control only for certain folders, you should do:

  • Implement methods enable and data in a separate file and return them in an enclosed object.
  • Register this file which returns object containing enable and data methods as an extension to the “csui/controls/treebrowse/navigation.tree” in the respective module.
"csui/controls/treebrowse/navigation.tree": {
    "extensions": {
      "RMExtensions": ["RMExtensions/controls/treebrowse/RMExtensions.treebrowse.tree"]
  • Enable method should return a condition that specifies when the Tree Navigation should be enabled.
  • The data method should return data that must be passed to tree navigation while instantiation. This data should include configurable settings. If there is no data to be passed default settings are applied.


define([], function () {
  'use strict';
  var RMTreeView= {
    enabled: function (status, options) {
       var supportMaximizeWidget = $("body").hasClass("csui-support-maximize-widget");               return (supportMaximizeWidget && $("body").hasClass("csui-maximized-widget-mode") === false);
    data: function () {
      return {
        "lazyTree": true;
    sequence: 50
  return RMTreeView;

A more complex enabled function (like in the index.html) is

enabled: function (status, options) {
var parent_id = status && status.container && status.container.get('parent_id');
return !!parent_id;


  • Parameters thats need to be included as part of module config:
    • sequence – number default: 100 Decides the priority of a module when multiple modules enabled treeview.
    • enable – function controls whether the treeview command should be visible or not. Need to return a logic whether tree view command is visible.
    • data – function Returns an object of data that are passed to treeview. The parameters that are returned by the data method are passed as options to the constructor of node.tree.view.
    • Parameters that can be returned by the data method are::
      • lazyTree – Boolean default: false Decides whether to prefetch items at one level ahead to display without any delay on clicking showmore button / to fetch the items after clicking show more button.
      • showItemsBlockSize – Number default: 10 Number of items that are shown on expansion of any node or clicking on showmore button.
      • rootNodes – Array of nodemodels default: top most ancestor node of the currently active node An array of nodes which are used as root nodes by the tree. If more than one root node is provided then multiples root nodes are displayed.

Happy Tree Browsing!

The magic of Extension Points: the csui-ext module

require js

Have you ever thought of the magic of extension points in smartUI?

What is an extension point?

This are the dynamic configuration points of smartUI. Calling the config URL in smartUI, you will see all extension points with all configured extension modules in the current smarUI. Normally you’ll add your modules in the file <your-base-requirepath>-extensions.json in your projectstructure build by yo.

All of these modules indicated by these json files are loaded at initialization and form the dynamic smartUI system.

This is an example of an actual configuration in a Content Server System :

Extension Point

As you can see in the configuration, an extension point allows the extension of the extension point with several definable extension modules. Ok,this sounds like a typical lawyer sentence.

In plain english:

This technique allows you to extend the capabilities of a base module (the extension point) with the extension modules listed.

How to add your own extension point?

Use cs-ext as requirejs extensions. This is part of the SDK (/lib/src/csui/utils/load-extensions). There is the module and a very brief short documentation.

If you want more infos on custom requirejs modules, refer to the example of a conditional module,

This is a require.js module like the one which I introduced for conditional loading in Febr 2020. cs-ext is part of the smartUI core. If you want to modify the cs-ext, then use the easy way of loading an requirejs extension described in the conditional loading article.

Overview of cs-ext (in the sdk)

Lets take a look at cs-ext. But if you are more interested in the usage of cs-ext, skip the overview and go to the next chapter “Usage of cs-ext” below.

define(['module', 'csui/lib/underscore'], function (module, _) {
'use strict';

The cs-ext requires only module and underscore.

var config = _.defaults({}, module.config(), {
ignoreRequireErrors: false,
modulePrefixesToRetry: [
'csui', 'classifications', 'esoc', 'wiki', 'workflow', 'webreports'

This is the standard entry to add sme vars into the configuration. Interesting is the list of modulePrefixesToRetry, includes all modules to retry a reload, if the extension point loading fails.

function handleSuccess(onLoad, parameters) {

The success handler, handles the callback

function handleError(error, onLoad) {
if (config.ignoreRequireErrors) {
console.warn('Loading extensions of "' + name +
'" failed:', error.requireModules);
} else {

The error Handler

function retryLoading(require, name, modules, onLoad, firstError) {
var droppedModules = [],
selectedModules = .filter(modules, function (module) { var slash = module.indexOf('/'); if (slash < 0 || .contains(config.modulePrefixesToRetry,
module.substring(0, slash))) {
return true;
} else {
if (selectedModules.length && droppedModules.length) {
console.warn('Loading extensions of "' + name +
'" failed:', firstError.requireModules);
console.warn('Dropping extensions:', droppedModules);
console.warn('Retrying extensions:', selectedModules);
function () {
handleSuccess(onLoad, arguments);
function (error) {
handleError(error, onLoad);
return true;

The retryLoading handler. Demonstrates how the reload a module, if there is an error condition. Only the modules with the prefixes listed in modulesPrefixesToRetry (see above) will be reloaded.

return {
load: function (name, require, onLoad, runtimeConfig) {
if (runtimeConfig.isBuild) {
} else {
var moduleConfig = runtimeConfig.config[name] || {},
modules = moduleConfig.extensions;
if (modules) {
if (!.isArray(modules)) { modules = Array.prototype.concat.apply([], .values(modules));
if (modules.length) {
function () {
handleSuccess(onLoad, arguments);
function (error) {
if (!retryLoading(require, name, modules, onLoad, error)) {
handleError(error, onLoad);
} else {
} else {

The main method is simply returned as js object.

All listed modules in the extension point list will be loaded and executed before the callback (the carrier module with the cs-ext entry) will be executed.

This may sound quite theoretical. Lets use cs-ext.

Usage of cs-ext

  • Select the module which you want to amend with an extension point. Lets use the csui/controls/table/cells/cell.factory (MUST exist) as an example.
  • Configure the proper extension in the project json like

  • Open the cell factory and examine the source code.

Notice the csui-ext! line at the end of the define-module list. This will search the require.config entries to get a list of the extension modules for this extension point. All listed modules (here hello.view) will be loaded and executed before the callback (stated in the line csui-ext) will be executed.

Back in the callback , the _.extend function extends the prototype of the cell factory by the methods “hasCellViewByOtherKey” and “getCellView”.


To make a custom extensible module (with extension point), add the csui-ext requirejs extension to your module and set the modules to be loaded in the appropriate json extension file.

Then point to your extensible module from your widget, and you are done. Then your module is configurable and extendable by using the csui-ext util module.

If you want to extend existing modules, you’ll have to spawn the widgets from the library to reflect your new module.