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.
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
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.
Optional declaration
Second, we must add a require.js module called optional doing the job
The require.js optional module
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 aqoute
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
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.
The perspective for the greeting/:id simply displays the greeting widgetThe perspective for the greeting displays the hello widgetThe extension points for the router
And this thing works (see these screenshots)
URL localhost/cs162/cs.exe/app/greetings calledURL localhost/cs162/cs.exe/app/reiner called
Imagine the possibilities. You can add a bunch of functionalities to the client all with an URI, which can be behind a link or a button.
Quite powerful, the smartUI sdk! You will love your routers.
Manage Cookie Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.