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:
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.
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?
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:
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).
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.
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:
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.
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.
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.
Lets see the initial command set. The Copy Command is here as usual.
After the red button is pressed in the then the Copy Command is gone:
We simply deleted the Copy command from the list of commands. This means, a simple Refresh will restore it.