Yeoman & generator-csui-extension secrets

Yeoman and smartUI

Have you ever wondered about the yeoman and the genererator-csui-extension? And whats going up in the somewhat bumpy installation and generation of a project dir? This are the Yeoman & generator-csui-extension secrets.

Yeoman & generator-csui-extension secrets: Lets unveil this secrets

First, recap the installation steps from scratch:

  1. Download and install node.js Version 11.15.0 (In you try a newer version, you will be rewarded by the famous primordials not defined error on starting yo, see this post )
  2. Set npm (part of node.js) to npm version 3 globally (npm install -g npm@3 (I am using 3.3.10)
  3. Install the grunt cli globally (npm install -g grunt-cli@1)
  4. Optional path: Unpacking the sdk and setting up the sampes)
    1. Unpack the SDK in a folder (p.ex. sdk)
    2. go inside this folder
    3. Use npm to install all requirements (npm install)
    4. Then you can start the internal webserver (Default under post 7777) by npm start and browse to sample-index.html inthis dir. Here you will get a listing of certain samples.
    5. The doc folder contains a very basic documentation of the smartUI SDK
  5. But for practical work, you need to gererate at least one project folder. This is a complete structure, containing the actual sdk and a place to build your own packages. So lets generate a project folder named project
    1. Preparation, only to do once
      1. unpack the gererator-csui-extension to a dedicated folder (p.ex. generator)
      2. While not(!) in this folder, install yeoman globally (npm install -g yo@1)
      3. go inside the folder generator
      4. link this as an extension to npm (npm link)
    2. Lets generate the project folder
      1. make the folder named project
      2. go inside the folder named project. Its empty
      3. Start yo to execute the csui-extension (yo csui-extension)
        1. you need to define the name of your oscrippt module and the requirejs base name. Then its doing a lot.
        2. Now your project is really full. You can optionally add a demo widget (yo csui-extension:widget)
      4. Now, build the project (grunt)

Ok, now the project folder project is operable. Lets take a close look on the generator.

(Remark: The versions mentioned are the working versions in my dev machines. Other, newer versions may work, but this is not guaranteed.)

Close Look at the Generator

When you do a npm link, a symbolic link is is build from the folder to [roaming dir]\npm\node_modules\generator-csui-extension.

Symlink Generator and Yeoman

So the extension folder is used as input for the yo execution.

Our Generator source folder looks like

Mann Content of the Generator

The app folder here is interesting

App folder of the Generator

First lets take a look on the rest of the templates folder

Some deeper folders in the hierarchie

Here we see, we have the same structure as lib…. in the sdk. SO the complete SDK is copied fron the generator folder to the project dir unter lib. There is no need to use the sdk folder (except for docs and samples)

A closer look at index.js (Excerpt). This file is executed during “yo csui-extension”.

Index.js

Here you see, the whole structure is copied directly from the templates folder to the destination project. All contents in this templates folder are later in the project folder.

A closer look at package.js

Package.js

The package.json contains as always the definition of this generator extension like, name, description and depedencies of this extension.

Areas for Customizations are at this areas (for example):

  • Custom gruntfiles, which shoulkd apprear in all new generated project folders
  • A different setup for the linters which should apprear in all new generated project folders
  • Added libraries
  • Added documentation structures

How to do this

Simply modify the generatot folder, add your customizations and modifications. You can save this folder as .zip to distribute internal standards.

Happy Customizing

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.

Enable

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

define(['module',
'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.

Example

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

  • 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) {
onLoad(Array.prototype.slice.call(parameters));
}

The success handler, handles the callback

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

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 {
droppedModules.push(module);
}
});
if (selectedModules.length && droppedModules.length) {
console.error(firstError);
console.warn('Loading extensions of "' + name +
'" failed:', firstError.requireModules);
console.warn('Dropping extensions:', droppedModules);
console.warn('Retrying extensions:', selectedModules);
require(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) {
onLoad();
} else {
var moduleConfig = runtimeConfig.config[name] || {},
modules = moduleConfig.extensions;
if (modules) {
if (!.isArray(modules)) { modules = Array.prototype.concat.apply([], .values(modules));
}
if (modules.length) {
require(modules,
function () {
handleSuccess(onLoad, arguments);
},
function (error) {
if (!retryLoading(require, name, modules, onLoad, error)) {
handleError(error, onLoad);
}
});
} else {
onLoad([]);
}
} else {
onLoad();
}
}
}
};

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”.

Summary

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.

The famous “define is not defined” Error (or “Mismatched anonymous define modules)

Famous Image Problem

In the content server 20.4 you’ll encounter from time to time a requirejs error “define is not defined”. Normally on defining icons. This is very entertaining.

In 16.2.10 the same thing worked as a charm.

Dont panic, in the “Hitchhikers Guide to the Galaxy” you’ll find the solution.

42 (As always)

(Just kidding. Lets be serious.)

Serious

The case in 16.2.10:

Screenshot in 16.2.x

In 20.2 and above

The same perspective in 20.2 and later

Ups. Looking insane.

Cure

Examine the browser console output. At the debug level.

Browser Console
Browser Console

As a nice addition for the entertainment, the module is uglyfied, it makes no sense to search for this strings, as they are produced during the grunt tasks. But on the other hand, a couple of lines further down there are some complaints of the grid.view.js that the “getSpritePath” is missing. And the offending module is supposed to return the getSpritePath function.

So, a search on getSpritePath gave the offending module, the sprite.js, which was introduced in 20.2 and is obviously required, when a widget wants to display sprites.

The module shows

Original Sprite.js

Lets consult the requirejs error page mentioned in the browser console.

Requirejs Error page

A check of stackoverflow.com gave me the resolution “name collisions can produce this” so I changed the sprite.js to

Changed sprite.js
Changed Sprite.js

Changed the function argument from require to requireReiner. The name doesnt matter.

Result

Everything runs under 20.2 like it used to in previous releases. No more mismatched anonymous define() modules.

But be careful: You’ll get the old js file in all new SDK releases. You should override the old file with the corrected one in all js projects.

As always:

Disclaimer: This works for me. The usage requires proper testing and I will not be liable for any problems whatsoever on that.

System Messages (in the smartUI Welcome Widget)

System Messages in smartUI

Remember the System Messages in the Content Server? This is an handy tool to display system related messages, like: “Next weekend we have maintenance” to inform users on issues with the system.

Normally, System Messages are added or deleted in the Admin pages. Here is an example:

How to add or delete system messages

A name of the Message, the message itself, an option URL for any explanatory pages and an effective date build together the System Message. Per default the System Message has a timeout period of 2 days after publishing, but this can be set in the opentext.ini file by setting a value to NewsDFTExpiration.

From this source the System Messages will be displayed in the legacy gui like this

System Messages are displayed in the legacy gui

But whats if somebody uses smartUI? Unfortunately, there is no possibility to display System Messages in smartUI.

Until the otherwise senseless Welcome Widget is amended. It can look like this:

System Messages in smartUI
System Messages – the new feature in the Welcome Widget.

(Disclaimer: This widget is NOT in the OpenText SDK. This is made by me. Contact me if you interested in using that)

The widget gets its system messages directly from an REST call which extracts this Messages and delivers them to the widget.

The news player is basically an unordered list with an <li> for each news entry. all news were rendered in the <ul> This is a screenshot of the handlebars template.

If any url is in the System Messages, the link opens up in a new tab or a new window.

The news entries scroll with a pure CSS3 animation, no additional Javascript is needed for that. Here is the animation part of the news

And the magic of animation is done with this:

And suddenly the Welcome Widget supports System Messages.

Nice, isn’t it.

Hidden Gems in the smartUI SDK: The side.panel

An overview of the side panel

One of the most interesting controls in the SDK is the side.panel. Reminds somehow to the good Documentum side panels, but is native in the new SDK for Content Server 20.4.

This can be used as a simple control to show things like search forms or oanything you like. Also, multiple views (slides) can be shown in a “Wizard Style”.

First lets take a look on the the sidepanel right out of the box. Quite astonishing, there is a index.html actually working under csui/controls/side.panel/test/index.html. If somebody starts this file, we’ll see side.panel in action:

Shows a nice panel sliding from left/right based on the configuration. This view can be used to show a single view or multiple views (as slides) as per configuration provided to it.

Quite interesting is the fact that if slides provided to the panel, panel’s footer include navigation buttons along with the button provided to the respective slide as part of configuration.

side.panel has modal (dialog) behaviour by default which optionally can pass using constructor param as well (options.modal).

There are several usage possibilities.

Simple Usage (on the right of the screenshot above):

var sidePanel = new SidePanelView({
title: 'Simple Usage Title',
content: new Backbone.View(),
buttons: [{
label: 'Button1'
}]
});
sidePanel.show();

If you want to have several buttons on the footer (in the middle of the screenshot above):

var sidePanel = new SidePanelView({
headerView: new Backbone.View(),
content: new Backbone.View(),
footer: {
leftButtons: [{
label: 'Button1'
}],
rightButtons: [{
label: 'Button2',
id: 'btn2'
}]
});
sidePanel.show();

An example for a “wizard style” sidepanel sliding from the left or the right into the screen

var sidePanel = new SidePanelView({
slides: [{
title: 'Step1',
content: new Backbone.View(),
buttons: [{
label: 'Reset Form',
className: 'binf-btn binf-btn-default'
},
{
label: 'Search',
disabled: true
}]
},
{
title: 'Step2',
content: new Backbone.View(),
buttons: [{
label: 'Finish',
close: true,
className: 'binf-btn binf-btn-primary'
}]
}]
});
sidePanel.show();

There is also a documentation available, at csui/controls/side.panel/doc/side.panel.view.md

Nice, isn’ it?

Happy sliding !

Remove Commands from Nodestable etc in the smartUI SDK

Command is Gone

From time to time you’ll need to remove commands from the widgets, like the nodeslist widget.

The magic spice is setting up a blacklist on the masks.js files during the initial phase:

csui.require.config({
  config: {
    'csui/widgets/search.results/toolbaritems.masks': {
      'mycustomer': {
        'otherToolbar': { blacklist: ['Properties', 'permissions'] },
        'inlineToolbar': { blacklist: ['Properties', 'permissions'] }
      }
    }
  }
})

There are several possibilities to do that.

1, The approved way

The approved way is to configure smartUI before its initialized from OScript.

This can be done by overriding the GetDynamicConfiguration in your base smartUI module (the one with the csuiextension orphan) like:

override function Assoc GetDynamicConfiguration(Object prgCtx, Record request)
  
    List blacklist = { "Copy", "Move" }
    return assoc{
      "csui/widgets/nodestable/toolbaritems.masks": assoc{
        "basecsui": assoc{
          "tableHeaderToolbar": assoc{ "blacklist": blacklist },
          "inlineToolbar": assoc{ "blacklist": blacklist },
        }
      },
      "csui/widgets/nodestable/headermenuitems.masks": assoc{ 
        "basecsui": assoc{ "blacklist": blacklist }     }    }
  end
end

Here in this example, the toolbaritem.masks and the headermenuitem.masks are set up with our magic spice (a blacklist containing all the signatures of the commands not desired). This will remove the “Copy” and “Move” commands from the list of commands permanently. And permanently means, this will survice a Page Reload.

2. The ugly way (but also surviving a Page Reload)

The ugly way is a way is the standard OpenText Way of overriding app.html and configuring the blacklists by yourself. Lets take a look at the app.html (found at ../core/module/csui/html).

Here is an example on a windows server:

Where to find app.html
app.html - the head

In the upper part you can see the csui.require calls. At the top you’ll notice a csui.require.config call, where you can put our magic spice (see above).

The disadvantage is, when you override app.html (directly or by using htmlmap) then you’ll have to check, if any future OpenText patches will override the app.html also.

BUT: If you override app.html, you can take advantage of this for example by implementing a permanent footer, which is always drawn at the bottom. You cannot do that with pure smartUI tools.

Here is an example of a permanent footer in the body part of the app.html.

Multiple usages of app.html - the body

3. The force way

There is also a brutal way to remove commands without that configuration of app.html. This requires

  • a widget or a command to do the removal
  • a couple of js lines

But on the other hand, this is the way which allows easy recovery of the command by doing a simple refresh of the page.

Here is a demo case (a wild version of the hello widget from my training installation). This is a widget with some demos and a new inserted button to delete a command.

a very chaotic demo

Behind the button are some js lines of code, which will remove the Copy-Command. Actually, the lines var b=commands.get(“Copy”); and commands.remove(b); do the job.

You will have to require /csui/utils/commands unter commands to use this two lines.

Two lines to decide the fate of the copy command.
Two Javascript Lines will decide the fate of the copy command

Lets see the initial command set. The Copy Command is here as usual.

Copy command lives

After the red button is pressed in the then the Copy Command is gone:

Copy Command is gone

We simply deleted the Copy command from the list of commands. This means, a simple Refresh will restore it.

Have much fun on playing around with commands!

Hidden Gems in smartUI: The Wizard Control

The wizard in Action

From time to time there are real gems waiting to be discovered in the deep abyss of smartUI. Today we’ll take a look on the Wizard control.

Example

Lets look at an example.

Hidden inside the permission explorer, there is an option to assign a new user with some permissions to a document.

When you select a document, you can select a user or a group to add to this document. This is the first page of our wizard. This control directly calls the MemberPickerWizard with this two steps.

Step 1: Select user or group

Wizard Example: Step 1

Step 2: Assign permissions

Wizard Exapmple: Step 2

Nice thing.

The code definition

Lets look at the member picker wizard:

var membersPickerDialog,
    dialogClass = "cs-permission-group-picker",
    dialogTitle = "Add users or groups",
    displayName = "Users and Groups",
    context = new PageContext(),
    connector = context.getObject(ConnectorFactory),
    node = new NodeModel({id: 37474}, {connector: connector}),
    startLocations = ['all.members', 'member.groups'];
membersPickerDialog = new MembersPickerDialog({
  command: 'adduserorgroup',
  context: context,
  connector: connector,
  dialogClass: dialogClass,
  displayName: displayName,
  dialogTitle: dialogTitle,
  startLocation: 'all.members',
  adduserorgroup: true,
  addButtonLabel: lang.AddButtonLabel,
  startLocations: startLocations,
  nodeModel: node,
});
membersPickerDialog.show();

Almost immediately the memberPickersDialog is instantiated and shown:

The membersPickerDialog

As we can see, here is our wizard.view.js used as reference.

The wizard itself is wired inside the prototyype:

Show the wizard

First, the steps are created in _createWizardSteps (see below).

All of these steps are used as argument on instantiating the wizard. Then the wizard listens to some events (“save:result” and “add:member”) and processes them.

Thats all. Easy.

The Step Defnitions

Steps are defined inside the _createWizardSteps method:

Define the steps

The object step1 defines the selection of the users, the object step2 (below) defines the permission level.

Example of a step: The Step 2

All steps have in common:

  • a title
  • headers (with the NLS language sting, a class and an id)
  • a next Button (with next button label)
  • and, of course, a view defining the content of the wizard step.

At the end, the defined steps are returned as array:

return [step1, step2, step3];

So you`ll find that under

csui/controls/wizard/wizard.view

Happy wizarding

smartUI in practice: SMART TOOLS(4) –Direct Access of Renditions – Technical

smart tools
Cell Renderer

Overview

Last week, we discussed a possible implementation of the direct access to renditions. This icon is drawn an a document, which das renditions at the newest version. Clicking on that icon opens a panel which lets the user select one of the renditions to download or delete.

Direct Access Rendition

Selecting one of the renditions will download this rendition or (if permissions allow it)( delete the rendition.

Technical

The whole thing is based on a cell renderer. This relies on the extension point node.state.icons which is (as always) declared in the extensions.json file:

"csui/controls/table/cells/node.state/node.state.icons": {
"extensions": {
    "csuia": [
       "csuia/cells/node.state/node.rendition/node.state.icons"
             ]
      }
},

This declaration points direct to the appropriate node.state.icons

define(['csuia/cells/node.state/node.rendition/rendition.view'
],
function (RenditionView) {
'use strict';
return [ { sequence: 60, iconView: RenditionView } ]; });

This basically declares the required view named “rendition.view.js” as responsible to draw the icon at sequence position 60.

This is the template used for the view.

Cell renderer Template

The image is drawn cia the css seen above.

Encapsulating this inside a link allows to make the svg clickable.

Enable the direct access

The first point is the decision, if the cell renderer is to be drawn or not. This is a static method at the view, returning true or false. We dont have ony clue if the nodeid does have a rendition at the newest version, so we have to implement a new REST command at the server to get the information. The REST must be called synchronously.

the static enable function

This is done via a simple XMLHTTPRequest. If the result is true, we return true and store the number of each rendition types at the node in the prototype for further processing.

Then lets take a look on the events:

events

This means, a click on the class of our link in the template will call onOpenView. Before we look at that, look at this in the templateHelpers:

Open the Panel after the click

Remember, we got the number of each rendition types from the server? We want tzo display these numbers as a tooltip over the icon, so this is the way to formet the output string. A note to the knights of the holy JS-grail: Referencing this.__proto__ instead of finding the prototype via object maybe depreciated, but at least its also in ECMA 6! So nowadays its a valid method.

When we click on the icon, we want to open a DialogView from the sdk toolkit with an embedded view (SelectView) in the method onOpenView:

OpenDialog

Before we open this view, we call the server to get the renditionlist of this node via XMLHTTPRequest. If we get the list (status=200) we intiantiate the view (selview1) and display the DialogView containing the instantiated view at the bin_modal default EL anchor.

Then lets show this region and store a event handler (string “submit”), which is listening on the view selview1 for that string. If it receives that string, the DialogView is closed.

Next week, we’ll examine the SelectView.

Missed something in the Posts? Here are the parts already posted:

smartUI in practice: SMART TOOLS(3) – Renditions

smart UI in practice: SMART TOOLS(2) – Multilingual Metadata

smart UI in practice: SMART TOOLS(1) – the beginning