16.2.11 | The Joy of Content Server

February 21, 2021February 22, 2021

Activating missing Webreport 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:

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.

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.

February 28, 2020February 28, 2020

Conditional Configuration with require.js in OpenText smartUI

When you write a widget or something else in smartUI, you encounter (from time to time) the problem to provide your widget with different configurations.

Like one widget provided as DashBoard for Music Events and lateron provide the same Widget as Dashboard for Race Events with different Logos Graphics etc. Require.js conditional loading of a module will help.

The idea is, if a conditional configuration module exists, it will be loaded and override the standard configuration. If its not present at the defined place, it wont load this and use the existing configuration.

Lets see an example:

in a view, we define a config.js containing all configuration stuff of this module

The main View with the config.js declaration

This will load configration values like

Mid of the configuration Module with the value "backgroundcolor" which we want to override — We want to override the value “backgroundcolor”

So far so good. When we want to override for example the value “backgroundcolor”, we can do that by editing the file, but we would have to redo that for all diffenent configurations. Its much smarter to define an optional require.js module, that will be loaded if present.

Our alternative config.file is called targetconfig.js.

Here are the values to replace the original ones.

For simplicity it contains only the value “backgroundcolor”.

The logic is:

If targetconfig.js exists, it will be loaded with require.js and replace the specific contents of the original config.js file with the contents in targetconfig. If its not existing, its simply doing nothing and the original config will be used.

How is this done?

First, we have to declare the additional targetconfig.js in the define area as optional.

Second, we must add a require.js module called optional doing the job

Now, we can use this in our wonderful widget providing as much configuratíons as we want – based on the existence of this config files.

Welcome to the Wonderful world of OpenText smartUI!!!

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

February 13, 2020February 13, 2020

Routers in OpenText SmartUI

Inside a Single Page Application, a router will take care of that what a URI used to do for you in a classic Client/Server application, it will intercept the URIs from beeing send to server and decide based on the URI whats to do with it. All within Javascript (we are not talking about html5 push state, thats another story)

Normally, the router will change the perspective (the display page) depending on the URI. For example, if an URI is http://<yourserver>/app/greetings, the Router will change the perspective to some new widgets and display the contents.

There are 4 routers build in the sdk (all in csui\pages\start\impl)

node.perspective router
switches to a different node
landing.perspective.router
used to address landing pages of the users
search.perspective.router
switches to the search perspective requested
Perspective.router is the parent object of all routers in the sdk

A router changes the perspective, for example a node perspective

var nextNode = context.getModel(NextNodeModelFactory);
nextNode.set(‘id’, 2000);

Normaly these routers shoudl be enough for standard usages, but if you need your own router, the next example can bring some light into a routers anatomy.

Scenario:
there are two routes in an URI, “greetings” and “greetings/:id”.

“greetings” clears a greeting subject, which was initialized from the model factories) and sets the id and “greetings” in the application scope

“greetings/:id sets the id in the greetings subject

_updateURL constructs the URL and moves to this URL.

Next, we neet plugin with two tasks:

–Get/create the model and switch perspective depending on the subject
- In _fetchHelloPerspective
–Set the greetingSubject in the constructor

Thed greetings router plugin — Process local perspectives with a plugin

We defined two routes, so we must provide two perspectives. We want to load them not from the server, so we need to define them locally als json arrays.