(WebReport) widget not loading fully when navigating in the Smart UI

Hi,

We are noticing some strange behaviour with some of our HTML WebReports Widgets in the Smart UI when navigating between tabs/pages.

To make user of jQuery, ModalAlert and some other libraries of the Smart UI, we're using the csui.require() function in our HTML webreports, for example:

// Code here
});
</script>

However, it seems that sometimes the code in this csui.require() block is not executed, when the widget is loaded from another tab, or in some cases when navigating between workspaces.

Are there other functions besides csui.require that could be useful to use in WebReports widgets? I've seen csui.onReady and csui.onReady2 on these forums, but I'm not entirely sure what they all do. Is there a function to check if a widget is being loaded, or when the user is navigating between pages, or when a page has finished loading?

Thanks!
- Mathijs

Find more posts tagged with

Comments

Ferdinand Prantl

Whenever the HTML WebReport widget is loaded and rendered, your WebReport output (HTML markup) gets appended. Make sure, that you use CS 16.2.0 (2017/03) or newer, which allowed using <script> elements in the HTML output.

When you navigate among pages (perspectives), all widgets are re-created and re-rendered. Events about page and widgets loading are not needed, because your code will be executed, when the widget is rendered.

Is the csui.require() block executed only on the initially activated tab, and on other tabs not at all? Or is it executed and/or not executed intermittently?

About methods requiring modules

"csui.require" ensures, that the specified modules are loaded and initialized, before its callback is called. Just what the RequireJS API documentation says about "require". Use it, if you need to require a couple of modules in an already initialized Smart UI application.

"csui.onReady2" performs the following steps:

Enables loading of the UI language selected by "csui.setLanguage".
Calls "csui.require".
Waits until the HTML DOM is fully loaded.

Use it on a custom page, where you load and initialize Smart UI. It can be called multiple times or used instead of "csui.require" too.

"csui.onReady" remains on the interface for compatibility with CS UI Widgets 10.x. It loads FolderBrowserWidget and TargetPickerDialogWidget and puts a couple of objects to the "csui" namespace. I recommend use use "csui.onReady2" instead of it.

Mathijs Depuydt

Thanks for the thorough response! We're currently on 16.2.0 with the latest patches.

In some cases we're using jquery to change the style of the widget 'tile' that the WebReport is being ran in, or we try to change something in the HTML (e.g. the Tile Header/Footer) of the tile. I've noticed that sometimes the javascript inside the csui.require() block runs fine, but the changes we attempt to perform to the tile seem to reference a previous DOM element after a new page is rendered.

I'll try some things and see if I can fix our issue.

Mathijs Depuydt

I managed to fix the issue in the WebReport. Like I suspected, it seems like after re-rendering, the jquery selector still was a reference to the previously rendered HTML tile, instead of the re-rendered tile.
In the element identifier I added an additional identifier (e.g. <div id="cust-tile[LL_REPTAG_WIDGETCONTAINERID /]"></div>), and then called it via jQuery as follows:

csui.onReady2(['csui/lib/jquery'], function($) {  $('#cust-tile[LL_REPTAG_WIDGETCONTAINERID /]').//code});

This way it does target the correct element in the re-rendered tile.

Ferdinand Prantl

Yes, you cannot initialize jQuery objects just once and use a global variable with them. The selector string may be the same, but every script execution needs to create a new jQuery object to work with. Perspective changes are not page loads, but the perspective is destroyed and rendered again. All old DOM elements are destroyed and new ones are created.

We try to avoid using ID attributes, when writing widgets, because it is not easy to ensure, that they are uniqeu on the page. They have to be unique to comply with HTML specification, but you may not know, how many times your widget or control will be placed on the page.

Instead of generated unique IDs and global searches, we obtain the parent element (parent widget) and then seatch by selectors within. When writing a complete widget, it is the "this.$el" property and "this.$(...)" selector helper. When writing script code for WebReports TileReport widget, it is not so easy to get the widget parent. For example, this code will work in all supported browsers, except for IE11:

var tileViewBody = $(document.currentScript).closest('.webreports-tilereport-content');

You should not need to tamper with the parent widget's frame, but I can imagine, that sometimes you need to know, what extents, what parent element you reside. We should want to improve this in a future version.