Differences Between Rendering Engines
DigitalSuite provides the following rendering engines for formatting and presenting web interfaces and their widgets on different devices:
- Application Runner: based on the Google Web Toolkit (GWT), a development framework for web applications.
Designers can select the rendering engine when they create a web interface. When designing and configuring the web interface with its widgets, some differences have to be taken into account, which are described in detail in the following sections.
Stylesheets and Styles
With Application Runner, layout and style settings are spread across a web interface and its widgets. With WIRE, all layout and style definitions are collected in a central stylesheet (CSS). In addition, WIRE comes with some out-of-the-box features that were not available with Application Runner, such as the central setting of a coloring scheme.
With both rendering engines, designers can add one or more custom stylesheets in the web interface settings. Templates are available which contain the predefined styles and can be used as the basis for the customizations.
The following table summarizes the differences between the rendering engines that are related to the layout and styling:
|CSS - general||Layout and style settings spread across each web interface and its widgets.||Layout and style settings collected in central CSS.|
|Colors||Definition of colors for the web interface and individual widgets spread in CSS.||Definition of a coloring scheme in the web interface settings. Additional color settings possible in central CSS.|
|Borders - web interface||Selection of a predefined layout and stylesheet with or without borders in the web interface settings.||Definition of border settings in a central CSS. The predefined layout has borders enabled.|
|Borders - widgets||Definition of borders in the settings of individual widgets.||Definition of borders in a central CSS. The predefined layout is without borders.|
|Text direction||Definition of the text direction in the web interface settings and in the settings of individual widgets.||Definition of the text direction can be configured in the web interface settings for WIRE. The default layout uses the left to right direction. The CSS global file can be used to seamlessly handle text direction for individual widgets.|
|Label width and position||Definition of the label width and position in the settings of individual widgets like input fields, lists, arrays, or execute script widgets.||Definition of the label width and position in a central CSS. In the predefined layout, labels are aligned left and above input fields or lists, and their width is optimized for WIRE.|
|Custom appearance of widgets||Definition of custom appearance using a class suffix for a style that starts with
||Definition of custom appearance using a class suffix for a style that starts with
|Tabs widget||Tabs can be placed at the bottom and the minimum height be specified in the widget settings.||Tabs cannot be placed at the bottom. The minimum height can be specified in a central CSS, for example:
|Custom widget||No global CSS; layout and style settings defined within the widget's elements.||Central CSS like for web interfaces, but without coloring scheme (the scheme of the parent web interface is used). The layout and style settings apply to the custom widget itself as well as to custom widgets it includes.|
|Checkbox and radio button lists||Limit columns count widget setting to display the values of the list in a specific number of columns.||No widget setting as not to impair responsiveness. The number of columns can be limited in a central CSS:
|API return values||Numbers are returned as String.
Objects and arrays are stringified. For example:
|Numbers are returned as Number.
Objects and arrays are parsed. For example:
|JS SDK||JS SDK must be added manually to web interfaces, if needed.||The required version of the JS SDK is included in WIRE. There is no need to add it manually to a web interface.|
Recommendation: The entire JS in a file should be enclosed in an IIFE to keep the DOM clean.
|JS in web interface settings||JS files and libraries can be specified for the header or footer to be executed before or after the web interface has been loaded.||All specified JS files and libraries are executed after the web interface has been loaded to avoid blocking and make sure that all screens and widgets are available.|
|Current screen||Known and controlled by Application Runner.||
|Read-only screens||Widget-specific settings||
|Custom widgets||No central JS; scripts defined within the widget's elements.||Central JS like for web interfaces.|
|Collections||Several JS functions have an option to execute them in synchronous mode.||Synchronous calls are no longer supported.|
The following table provides an overview of the differences between Application Runner and WIRE which apply to all types of widgets.
|Dynamic creation, placement, and removal||Widgets can be created, moved, and removed by API calls.||Widgets can be created, moved, or removed dynamically by API calls.|
|Widget ID||Specified by developers in the widget settings according to their needs.||An ID is required for each widget. If developers do not specify an ID in the widget settings, it is generated automatically and used internally for all screens. Generated IDs are not displayed in the widget settings.|
|Visible / editable / required rules||JS for each rule specified in widget settings.||Functions in central JS file:
An example is provided below.
|User input validation rule||JS specified in widget settings.||Function in central JS file:
With Application Runner, the following code can be specified as the editable rule in the widget settings of a text input widget,
id_text1. The widget is editable depending on the length of
With WIRE, the following code would be used for the same purpose in a central JS file:
1 2 3 4 5 6 7
Without specifying a condition, the function in the central JS file would look like this:
The following table provides an overview of the differences between Application Runner and WIRE which apply to specific types of widgets in addition to those for all widgets described in the section above.
|Widget Type||Application Runner||WIRE|
|Buttons||Pre-launch script for several types of buttons and script for Execute Script button specified in widget settings.||JS functions in central JS file:
|Indicators (spinners)||Can be created dynamically with JS.||Are implemented as SVG icons and cannot be created dynamically. The following API functions of Application Runner are not available:
|Lists and selectors||Post-loaded script in widget settings for all types of lists and selectors.||JS function in central JS file:
|Custom report||Loading data script in widget settings in addition to scripts for all types of report||JS function in central JS file:
See example below.
|Array||Rules for adding and deleting rows; footer script for individual columns and for overall array; script to execute when adding a JS widget as an array column.||JS functions in central JS file:
|Section||Rules for opening and closing the section in widget settings.||JS functions in central JS file:
|Tabs||Visibility rule, editable rule, and click script for each tab in widget settings.||JS functions in central JS file:
The relevant tab is specified by its index with each function.
|Application History widget||
If disabled, the HTML code is sanitized, removing any JS included in it.
|Upload widget||API functions to retrieve the widget's upload, download, and delete buttons, to set and get the upload button label, to get and set a tooltip, and to set the widget's value and execute an upload (required only for old Application Runner versions).||The following API functions of Application Runner are not available:
Report Widget Custom Column Script
setCustomColumnScript JS function for Report widgets takes two parameters:
- The index of the column.
- The callback function used to fill the column. The callback function takes the current row as a parameter and returns an object that contains:
content: the content to be displayed in the report cell (text or HTML)
afterCreate: a function to be executed after the content has been added to the column
beforeUnmount: a function to be executed before the column is removed from the report
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Custom Report Loading Data Script
setJsReportLoadingDataScript JS function provides the report content for Custom Report widgets. It takes a callback function with an
options object parameter that includes:
1 2 3 4 5 6
1 2 3 4 5 6 7 8
With Application Runner, accessing IDs and variables within a custom widget requires the
RMP_this.variable prefix, for example:
1 2 3 4
RMP_this.variable are not required to access a custom widget's own IDs and variables:
1 2 3 4
WIRE supports additional prefixes,
window, to address the IDs and variables of a custom widget's parent web interface or custom widget, or the root of a hierarchy of web interfaces and custom widgets, for example:
1 2 3 4 5 6
Every custom widget provides a
setLoadedCallback function. It allows to set a callback when the custom widget is loaded, so that its resources can be accessed from a parent.
1 2 3 4 5 6 7 8 9 10
Web interfaces based on Application Runner can be configured with listeners that trigger a composite API, connector, or process.
Whereas, for web interfaces based on WIRE, listeners that call Connectors are not supported. Instead, Composite APIs can be launched.
In summary, the differences between listeners with Application Runner and WIRE are the following:
|Action||Launch a composite API, connector, or process.||Launch a composite API or process.|
|Launch event||Specified in the listener configuration in the web interface settings:
||Launch functions in central JS file:
|JS upon event for composite API||Specified in the listener configuration in the web interface settings.||Success and failure callbacks of launch functions in central JS file - see example below.|
|JS upon process events||Specified in the listener configuration in the web interface settings.||Grouped into
Composite API Listener
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
The following table provides an overview of miscellaneous differences between the rendering engines which designers should be aware of when developing web interfaces.
|Autocomplete Input widget||
||The following settings are not available for web interfaces built with WIRE:
|Number Input widget||Formatting of numbers is based on the GWT format.||Formatting of numbers is based on Numeral.js. Any number pattern is supported, except for time and exponential patterns.|
|On/off widget||Implemented as a checkbox:
||Implemented as a switch:
Representation on the WebModeler stage:
|Icon in WebModeler Widgets tab:
Representation on the WebModeler stage:
|Date picker||Limited functionality.||Improved functionality and usability with date and range selection, filtering, manual input and display.|
|Captcha widget||Special effects designers can select in widget settings:
||Special effects designers can select in widget settings:
|Application History widget||
|Container||The web interface components can be opened in a modal window using the jQuery libraries.||The web interface components can be opened in a modal window using the container widget. The behavior is defined in DigitalSuite Studio using the following widget settings: