Activating missing Webreport Tabs

Missing Tabs

A short, but sometimes time consuming thing are the missing Webreport Tabs. Imagine, you have a Content Server with an jetty based internal Admin Server or an external Admin server on a fast machine.

The problem

Then, from time to time, you will see this on editing a webreport:

Missing Webreports Tabs

All Edit Tabs for the webreport are missing. Although you can start the missing functions within the URL, its annoying.

The Cure

If this happens, use this Magic Trick N,12:

Simply stop Content Server and Admin Server. Start the Admin Server and wait at least 5 min before starting the Content Server.

Magic Trick N.12 in Action

Then you’ll see everything is there.

Wow. You made it. You are a great wizard.

Seriously:

There is a timing problem in the Content/Admin Server. If the Content Server starts to fast, COntent Server thinks, there is no license for webreports at first. Later, it gets the license, but the GUI is drawn without the webreports tabs.

Wait for your Content Server to start up. Wait at least for 5 min. Then everything will be drawn in the GUI.

Happy webreporting.

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

smartUI in practice: SMART TOOLS(3) – Renditions

smart tools

In SMART TOOLS renditions are also build in the properties manager of smartUI. Renditions can be displayed by selecting renditions on the pull down menu, just like Multilingual Metatata in my last post.

The main menu

Rendition Main Panel

Next, the main panel of renditions is displayed. The renditions of the newest version or the latest 5 versions will be displayed.. A Rendition can be downloaded, deleted, replaced or (if configured) with “View as Webpage” be seen.

Rendition Commands

If there are a lot of versions, a starting version can be selected. Then this version and the last 5 versions with all renditions will be displayed.

Ascending or descending sorts on versions can be done by clicking on Versions.

Interesting is the “View as Wewbpage” function. This is a build in function in the Content Server, so it can also be used to see the contents of any renditions in the classic UI and in a separate window.

view as webpage display

A rendition can also be downloadeed by clicking on the down.arrow icon. This will normally download the file as setup by the users browser. If the rendition is a PDF and print.js (a standard extension in browsers) is activated, the the pdf can also be displayed directly.

A list of renditions can also be printed. This is a nice addition to help you to get an overview.

Rendition list

Direct Access Renditions

For a direct access to renditions, I also added a cell renderer to be displayed, if the newest version of the document has a rendition.

This is a little svg icon displayed directly in the list of documents.

Cell Renderer

The little icon can be clicked and then a list of renditions belopnging to this document is displayed.

Direct Access Rendition

From this panel, a rendition can be selected and downloaded. If the user has proper permissions, he can also delete the rendition selected. Also a printed list (see above) can be made at this point.

Sorting in ascending/descending versions can be done by clicking on the Arrow in the “Vers” columnn.

Because this direct access requires a lot of calls to the server, this feature can be switched off at the Admin Pages of smartUI.

Add Rendition Command

Additionally, there is also one command required, the “Add Rendition” command. The “Make Rendition” command is not implemented, because this requires local admin rights, something which should be rare.

This command can be issued at any document directly from the list of documents

Addrendition command

Commands are usually displayed in two locations, the Headertoolbar (above) and the Toolbar (below)

Command in Toolbar

Adding a rendition means, selecting one of system defined rendition types and a file beeing intended as the rendition. If the selected rendition type does not exist on that document, then the file is uploaded and used as a rendition.

Add Renditions - Panel

Next week, we dive more in the direct access of renditions and the Pros and Cons of that technique.

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

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

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

Using react components in smartUI environments

Optional Module

With the react-dom package this can be easier then expected. The idea is, add the react component directly to the DOM

Build Environment

When you have a project directory made by yo from the sdk, you’ll need a couple more node.js module:

npm install -save react
npm install -save react-dom

Then make the two files

react.js
react-dom.js

ready for use with require, either by directly requiring them or use the require in the src path of your development. Dont forget, you cant use the IMPORT statement, because its ES6. The exact procedure depends on your project build modifications .

First steps

The React component

define([
'basec/widgets/hello/impl/lib/react'
], function (React) {
'use strict';
class UserInfo extends React.Component {
render() {
var img = this.props.img, name = this.props.name, mail = this.props.title; return ( 
React.createElement("div", null, 
      React.createElement("img", {width: "100", src: img}),
      React.createElement("div", {className: "name"}, name),
     React.createElement("div", {className: "mail"}, mail)));
}
);

This component is a simple div containing an image link and two other divs with content (name and mail)

The sdk demo widget

Then use the sdk demo widget, which will be generated, if you tell yo to do so:

yo csui-extensions:widget

This will add a widget/hello tree in your source tree (if your name for the widget was hello), The first couple of lines in the hello.view.js are:

define([
'csui/lib/underscore', // Cross-browser utility belt
'csui/lib/jquery',
'csui/lib/marionette', // MVC application support
'basec/widgets/hello/impl/hello.model.factory', // Factory for the data model
'basec/widgets/hello/impl/lib/react',
'basec/widgets/hello/impl/lib/react-dom',
'basec/widgets/hello/impl/UserInfo',
'i18n!basec/widgets/hello/impl/nls/lang', // Use localizable texts
'hbs!basec/widgets/hello/impl/hello', // Template to render the HTML
'css!basec/widgets/hello/impl/hello' // Stylesheet needed for this view
], function (_, $, Marionette, HelloModelFactory, React, ReactDOM, UserInfo, lang, template) {
'use strict';
// An application widget is a view, because it should render a HTML fragment var HelloView = Marionette.ItemView.extend({

First we need react and react-dom as modules. They are added here via define. I put it in some weird place, but this is up to you where to put this two modules. There are also a couple of different possibilities to get react and react-dom inside a module.

Next, we need a place where we can add our react component. So lets add this in the hello.hbs file:

...
<div id="userreact">
And this is the react component
</div>

this is simply a div going to held out react component.

The react-dom plays its role

The react-dom can render the component to a designated element, something like the $el element. We added a div with the id “userreact” in the hbs file above.

Now we can render the handlebars template. In Marionette, there is an onRender event routine, which can be used to spice up any rendings of Marionette.

onRender: function() {
var name = this.model.get("last_name");
var mail = this.model.get("mail");
var img = this.model.get("photo_url");
ReactDOM.render(
React.createElement(UserInfo, { name: name, mail: mail, img: img }),
this.$("#userreact").get(0));
},

In the onRender function, all is rendered and we now have a DOM. Now we can render our component.

  1. We need to provide your component with some data. So we extract these from our userdata model we got from the content server. This is more or less the equivalent to our old friend template_helper
  2. The ReactDOM is supposed to render the element UserInfo with the parameters in our div with the id “userreact”

Housekeeping

When the Backbone view’s remove method is called (from the csui app from the content server), we need to remove also our react component.

So lets add our Remove in the Backbone remove()

  remove: function() {
    ReactDOM.unmountComponentAtNode(this.el);
    Marionette.View.prototype.remove.call(this);
  },

Btw: If you want to use jsx for react ui definitions, you should amend your build process with the babel transpiler. This is an example of jsx and quite different to javascipt.

const element = ( <h1 className="greeting"> Hello, world! </h1> );

The transpiler basically builds this structure

// Note: this structure is simplified 
const element = { 
type: 'h1', 
props: { className: 'greeting', 
        children: 'Hello, world!' } 
};

Summary

  • Install react and react-dom and make them requirable.
  • Build or get the react components. Make them requireable.
  • Require this components from your view.
  • Add an anchor to your hbs file.
  • Let Backbone-Marionette render.
  • In the OnRender callback, gather all data for your react component and let react-dom render the component to the anchon.
  • Use standard JQuery to get data from the react-component.

Some further infos (on pure Backbone/React things without smartUI reference)

Integrating React with Backbone

Using BackboneJS successfully with React (using MobX)

Thats it.

But nevertheless not often used in our OpenText smartUI practical live. 🙂

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

smart tools

This is the second part of a multipart post of the new SMART TOOLS – a product supporting mlm and renditions in smartui.

You can get the first part smart UI in practice: SMART TOOLS(1) – the beginning

Today lets look on the functionality of the multilingual metadata part of smartUI.

Its directly integrated in the properties manager of the nodelist widget.

The multilingual metadata panel

Use the pulldown menu in the properties manager.

If you go to the “Multilingual Metadata” entry, you’ll see a list of the two attributes, which make up the multilingual metadata in all supported languages.

Here, just for demo purposes, metadata languages are English, German, French, Italien, Japan, Spanish and simplified Chinese.

Automatic translation with Microsoft Azure services

At right, there is a globe icon visible. If there is a globe icon, then this language is configured to do an automatic translate using Microsofts Translate service. Its to translate from the users default metadata language (here English, also displayed with a different background) to this target language. Simplified chinese is not configured to use automatic translation, therefore there is no globe set at chinese. To configure that is the job the Content Server administrator.

Clicking on the globe will replace any text with the translation of the attribute in the default metadata language (here “a special cover letter”).

Although this translating machines are quite good, its always a good idea to have the opportunity to manual correct the automatic entries. Its done simply by clicking on an entry.

By pressing <RETURN> in a inpput field or by clicking on any language name, the edit mode is switched off and the green button “save mlm data” is activated. By pressing this button, mlm data is saved on the server.

Print a list of actual mlm data

If you have a lot of these language entries, its unlikely for one person to check all language values. It would be nice to have a list (printed of pdf) with the actual values. This can be done by simply clicking on the blue Print-Button.

This will open the browsers print window and give you a preview of the list.

Ok, thats all for today. Next week we’ll take a look at the SMART TOOLS Rendition support.

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

smart tools

Using OpenText Content Server as as developer, you have to face it sooner or later: Write an application in smartUI. This will give you a lot of experience for smartUI projects, especially on the Cost/Times/Materials base.

I did chose to build a product called SMART TOOLS with Renditions and Multilingual Metadata Support. Product means, it can be sold by other OT partners as well.

This is a multipart post. Today we talk about the basics of the application running in Content Server 20.2. Additional posts will explain the usage and some technical aspects

Features

SMART TOOLS includes these features:

  • Adds support for Multilingual Metadata to smartUI
    • Automatic Translations for the multilingual data using Microsoft Azure REST service (as nobody speaks all languages on this planet)
    • Add print lists (to get a list of the data entered for editing)
    • Add/edit mlm data directly
    • Integrated in the standard nodelist widget using the property manager
  • Adds support for Renditions
    • List all Versions and Renditions
    • Use “view as webpage” as a base viewer
    • Download renditions
    • Delete renditions
    • Replace renditions
    • Add Renditon as command
    • A cell icon marks all documents in the document list having renditions at the newest version. Clicking on the icon will open a window to show all renditions. Download or delete a rendition.
  • Adds configuration support for the javascript client software from the Admin pages. Critical things like MS Rest API key can be protected by sending this things at the page creation time to the client.

The SMART Tools are build for Content Server 20.2. A a considerable amount of new REST services also to be implemented in the Content Server.

The Integration

Integration is simply direct in the nodelist widget using the property manager.

Open the property manager

By clicking in the first icon in the list, the property manager opens.

Renditions and Multilingual Metadata

The panels adressed by this menu are the multilingual metadata panel (with the two fields Name and Description) and the rendition panel. Here you see the mlm panel with the autotranslate Icon (the globe at the right).

mlm main panel

This is the rendition panel which shows all renditions attached to all versions.

Renditions main panel

Language support

The SMART TOOLS support a couple of UI languages like

  • English
  • German
  • French
  • Spanish
  • Italian

This is one example on the multilingual metadata dialog using German, French and English.

The nls feature of smartUI is nice, isn’t it? I even tried it (experimental) for Arabic, and it worked!

Lets go more in detail in the next posts, as this here is intended to be a simple overview.

Next week I will describe the multilingual metadata support of smartUI

Agenda of the new 20.2 Smart UI Base Workshop

CSUI Components

Day 1 (10:00-17:00)

Chapter 1

Agenda. A short introduction to this agenda

Chapter 2 The different GUIs.

The new smart GUI. How smartUI works. Setting up landing pages with the new GUI. Using Perspectives and build them with the Perspective Manager. Use Webreports to build custom widgets. The new perspective element and the difference 20.2 to previous versions.

Using widgets on another portal w/o content server.

Exercises:

  • Build a custom perspective
  • Build a custom widget based on a web report

Content:

  • Chapter 2.1: The different UI Possibilities
    • Examples: Connected Workspaces
    • Examples: xECM
    • Examples: Documentum D2 Smart View
    • The Big Picture. See the GUI components in the Content Server Environment
    • Functional Components of the smartUI SDK
  • Chapter 2.2: smartUI Overview
  • Chapter 2.3: Diving deeper in the smartUI
    • Role-Based Content Server Pages
    • User Interface
  • Chapter 2.4: Perspectives Overview
    • Scenario: Creating a new Perspective
  • Chapter 2.6: The Perspective Manager
    • General Information
    • Rules for Role-Based Perspectives
    • Layout Behavior
    • Configure Widgets
  • Chapter 2.6: The Toolbox. An overview of the visual components in the SDK. The usage will be discussed later in the SDK

Day 2 (9:00-17:00)

Chapter 3 REST

REST. What is REST? Overview of REST Services

Chapter 3.1 REST. Consuming REST Services with Postman.

  • Using REST Services.
    • Authenticate a User
    • Test a REST Operation in Postman
    • Filtering and Expanding Data in the request
    • REST API Clients
    • Tips and Tricks.

Exercises:

  • Use POSTMAN to get used to REST, Authenticate in REST
  • Try several REST commands and get an overview over the various options
  • Build a REST based html page, which queries a node

Chapter 3.2 Extending REST Services.

How to build a new REST Service in OSCRIPT.

Exercises:

  • Build a custom REST Service in a new Content Server Module. Later in Chapter 10, this REST Service will be modified and be the server-side base of our first widget

Content:

  • Handling Requests with REST API
  • RESTful object
  • Create a module for REST extension
  • REST API module in Content Server 20.x
  • Resources, actions and prototypes
  • Adding parameters to the prototype
  • Test a new REST resource
  • Tips and Tricks for REST Services with smartUI
    • Table Query inside a REST Service
    • Getting nodes with complex categories
    • Handling complex Categories

Chapter 4 A very short intro to JavaScript Patterns.

That’s what any developer of the SDK sees inside the SDK. A short tour through the JavaScript patterns required to understand the SDK and the underlying frameworks. This is based on Stefanov “JavaScript Patterns” O’Reilly, ISBN 978-0-596-80675-0, which is very recommended. Some new Aspects of ECMA6, Promises, Deferrals are also discussed

Content:

  • Introduction and References
  • ECMAScript Versions
  • Chapter 4.1 The Patterns
    • Promises
    • JQuery Deferred
    • XMLHttpRequest
    • Immediate Functions
    • Immediate Object Initialization
    • Function Properties—A Memorization Pattern
    • Configuration Objects
    • Function Application (also with smartUI examples)
    • Schönfinkelizing or currying a function
    • Mix-In Inheritance copy all properties to a child
    • Borrowing Methods
  • Chapter 4.2: Object Creation Patterns
  • Chapter 4.3: Sugar methods
  • Chapter 4.4: Object Design Patterns
    • Singleton
    • Object Decorators (used quite often in the smartUI SDK)
  • Chapter 4.5: DOM and Browser Patterns
    • Web Workers (only in recent browsers) long running scripts

Day 3 (9.00-17:00)

SDK Infrastructure Intro

Chapter 5 SDK Infrastructure Intro

Introduction to Infrastructure needed for the SDK. All components and frameworks will be introduced. Introduction to Backbone with a Tutorial, Marionette as the extension of Backbone is also covered by a tutorial.

Exercises:

  • Backbone Tutorial. Building a browser-based TODO List
  • Marionette Tutorial. Extending the TODO List with Marionette

Content:

  • Chapter 5.1: Bootstrap
    • A CSS and JS framework as the base of smartUI
  • Chapter 5.2: Node.JS
  • Chapter 5.3: Require.js
    • Overview
    • How to use require.js.
  • Chapter 5.4: Backbone.js
    • Views
    • Events
    • Models
    • Collections
    • Routers
    • Models and Views
    • Collections
    • View Rendering
    • Routing with URLs
    • A simple Backbone Tutorial
  • Chapter 5.5: Marionette.js
    • Marionette Views – Layouts
    • Marionette Views – Regions
    • Tutorial: A simple Backbone-Marionette App
    • Recommended Tools
      • Backbone Debugger
      • Marionette Inspector
    • Python based client for mozilla-marionette
  • Chapter 5.6: Handlebars.js (Overview, more in depth in the advanced training)
    • A html template framework
    • Handlebars SDK usage
  • Chapter 5.7: Yeoman
  • Chapter 5.8 Grunt.js
    • Tasks Configuration
    • Starting grunt
    • Some examples of GRUNT tasks
    • CSUI sdk custom grunt tasks
  • Chapter 5.9 Additional Libraries. Here the libraries are quickly discussed. For a more in-depth discussion, please refer to the Advanced Workshop.
    • Short Overview of D3, the interactive SVG Graphics package inside the SDK
      • D3 GANTT Chart example
    • Short Overview of Alpaca, the forms package inside der SDK
      • Alpaca Example
      • Alpaca Support in the Content Server
  • Chapter 5.10 Additional Infrastructure
    • Python
    • CORS – Cross Origin Resource Sharing Chrome Plugin
    • Inkscape/wingrep/fiddler
    • SVG viewer
    • Markdown

Day 4 (9:00-17:00)

Chapter 6 smartUI Intro BASIC

What is the SDK, Prerequisites, documentation? Download and install the SDK.  Examine the structure. Style Overrides, an overview. We look at all framework homepages to find examples and documentation. Using fiddler to examine underlying functionality. What’s possible with the SDK. Discussion of how to add new node types, new commands. Discussion of the controls and the widgets in the SDK (basic level).

Exercises:

  • Find the SDK and download the SDK
  • Install the SDK
  • Build a Project Directory
  • Prepare the Demo Widget “Hello”
  • Install this in the CSIDE Module from Chapter 4
  • Test this widget in the Perspective Manager

Content:

  • 6.1 Introduction
    • Content of the SDK
    • How to develop
      • JS IDE Webstorm
      • JS IDE Eclipse
      • Notepad++
  • 6.2 Installing the SDK.
  • 6.3 Building the Demo Widget
  • 6.4 CSS Style Overrides Binf (OpenText Bootstrap Version)
  • 6.5 General Overview
    • General Architecture
    • Coding Guidelines
    • csui.onReadyx  
    • Logging, Internationalization and Localization
  • 6.6 Content of the SDK
    • The Connection Object
  • 6.7 Routing Preview (see adv. Training for a more detailed discussion)
  • 6.8 New Command
  • 6.9 Custom Column
  • 6.10 Metadata
  • 6.11 Define a new Nodetype
  • 6.12 Create a Widget
  • 6.13 Base Widgets. Detailed info’s on base widgets.
    • Favorites
    • Recently Accessed
    • MyAssignments
    • Shortcut (depreciated in 16.2.10)
    • Shortcuts
    • Metadata
    • NodesTable
    • Thumbnail
    • DocumentOverview
    • Search Results
    • node.state
    • Permissions and Permission Explorer
    • Html.editor
    • Navigation Header
  • 6.14 Controls and Contexts
    • Controls
      • Node Picker
      • Modal Alert
      • File Open
      • Perspectives: Grid, Single, Left-Center-Right, Tabbed, Tabbed-Flow
      • Tile
      • ListView
      • ListItem
      • Signin
      • UserPicker
      • Breadcrumps
      • Checkbox
      • Dialog
      • Disclosure
      • Error
      • Form – with alpaca.js
      • Globalmessage
      • Grid
      • Zip&Download
      • Visual Count Control
      • Integration Folder Browser
      • Integration Target Picker
    • Contexts
      • Detached objects
      • Permanent objects
      • Temporary objects
      • Page Context
      • Browsing Context
      • Perspective Context
      • Portal Context
  • 6.15 Models and Factories
    • NodeModel
    • Other Models
    • Factories
      • Fetchable Factory
      • Configurable Factory

Day 5 (9:00-16:00)

Rest of Chapter 6: SDK

The remaining parts of yesterdays SDK intoduction

Chapter 7 Mockup Data and Testing

MockJax is used to mock up data (no need for a Content Server during development of a widget) and the Jasmine Framework is used to for the testing of the widgets or other JavaScript modules

Content:

  • Mocking Up Data
  • MockJax
  • Setup and Usage
  • Jasmine Usage

Chapter 8 The anatomy of the example widget Hello.

A detailed voyage in the source of the widget. (Explanation of all js files, the test folder, css and language settings)

The Chapters 9-11 are exercises. Chapter 12 is a Real-Life Demo/Exercise. Depending on the time left, these parts can be cut down.

Chapter 9 The anatomy of the myAssignment Widget.

A detailed voyage in the source of the widget. (Explanation of all js files, the test folder, css and language settings)

Chapter 10 Add another Widget to the one already loaded.

Recap the complete workflow how to implement a widget from Unit7. Add the Greeting Widget (another simple Widget from the samples) to the Greetings Widget.

Exercises:

  • Add the Greeting Widget to the Content Server
  • Test using the Perspective Manager
  • Modify the widget (by doing several things as implementing a control from the library)

Chapter 11: Build a custom Widget (optional)

Our First Widget.

Use the Hello Widget, modify it to call the REST Service we build in Unit 3.2. Modify this REST Service to provide a better JSON Structure.

Exercises:

  • Modify the Hello-Widget. Add a model for our REST Service. Add a handlebar template to output our greetings from the server. Add some css effects

Content:

  • Subdirectory Structure
  • Some Changes to our REST Service
  • Files to create
  • Add mockup support, once the answer is clear defined
  • Test with index.html
  • Start „npm start “the local server in the dev folder
  • Compile the new bundles file with grunt
  • Install on Content-Server
  • Open the perspective manager
  • Problem with Chrome. Official Chrome BUG: (Issue 611328 https://bugs.chromium.org/p/chromium/issues/detail?id=611328)

Chapter 12: Strategies to “widgedize” an existing legacy gui module and to add things to an existing module (optional)

The strange word “to widgedize” stands for “Build a widget for a legacy module not already supporting widgets”. The Strategies on amending a Module by adding a widget and on adding additional functionality inside an existing widget are discussed. In the complete practical workshop, these widgets are implemented also on the Server side, whereas here no server implementations are made.

Content:

  • Moving from a legacy gui module to a smartUI module
    • Examine a legacy module and rebuild a smartUI widget (here only on the client side)
    • As an example, the barcode module
  • Add a functionality in an existing widget
    • Add an email functionality in the Connected Workspaces Team Widget.
    • Usable from inside the Widget

Handouts and Class Material

A share accessible for all attendees as source of this handouts is required.

Handouts

  • Reiner’s Cheat Sheet for CSUI Widgets
  • Reiner’s CSUI Workflow Cheat Sheet (advanced Session only)
  • Backbone.js Offline Manual (Offline Webpage)
  • Bootstrap 4 Cheat Sheet (Offline Webpage)
  • REST Demo guides Memberinfo and Nodeinfo
  • REST Demo Guide Create a REST Service

Class Material

  • Backbone Tutorial TODO Application
  • Marionette Tutorial TODO Application
  • Our first homemade widget
  • REST Exercises
  • myfirstNode.js
  • Material for Chapter 12 including the client side js apps

Training conditions

  • The training is remote using Microsoft Teams in these Corona times.
  • The training materials are in english, the trtaining lanbguage is english or german, depending on the geographical location.
  • The customer needs to setup a stand alone training VM with a Content Server and Database. A copy of these machine must be provided as the Trainer Machine to us, on which the training is held.

New: We are offering custom widget development. Interested? Send an e-mail to merz at ebit-company.de stating the purpose of the widget and requesting a qoute