Dynamic Server Pages

Dynamic Server Pages(DSP) components define the user interface of web pages that can be incrementally and dynamically updated. They can be used in rich interactive web applications and in cross-platform mobile apps.

When executed, this component generates the HTML required to present the data and the layout in the client browser. Dynamic server pages are split—a non-persistent part runs on the server, and a persistent part runs in the client browser or mobile app.

Communication between the two parts is asynchronous, via HTTP requests and responses over the internet. A JavaScript-based runtime engine in the client provides the mapping between the client and server sides of the component. For more information, see Component Instances.

Compiling a dynamic server page creates a deployable server-side file with the extension .dsp.

Dynamic server page components provide the following features:

  • Incremental and full-page updating at runtime.

    Unlike static server pages, which regenerate a complete page every time a request is sent from the browser to the server, dynamic server pages can update parts of the web page. This reduces the amount of data that needs to be transferred and helps to improve performance. For more information, see Client-Server Communication in DSPs.

  • Support for manipulating data from both the server and the browser.

    Uniface provides a JavaScript API for addressing data in the server page as JavaScript objects. This makes it possible to manipulate data in the browser (for example, changing the appearance of a field or exchanging data between embedded component instances) without having to go back to the server. For more information, see Executing Logic in the Browser and APIs: JavaScript.

  • Offline data storage

    Uniface provides a JavaScript API to enable you to store data as JSON documents on the client. This makes it possible to store DSP definitions, temporary data, state information, bookmarks, and so on the client. For more information, see Client-Side Data Storage.

  • Rich set of HTML-based widgets.

    Dynamic server pages have their own set of logical widgets for displaying data. Many of these widgets are mapped to HTML5 controls which can be rendered slightly differently, depending on the browser and the device. This makes it possible for a single widget, such as a date picker, to be displayed using the native appearance typical of Windows, Android or iOS operating systems. For more information, see Widgets for Dynamic Server Pages.

  • Multiple views for each component instance.

    Views provide a mechanism for providing alternative layouts for the same data. Each DSP can have multiple HTML layouts defined, which can be addressed as views using the JavaScript API. For more information, see Multiple Views for Dynamic Server Pages.

  • Nested components.

    The DspContainer widget makes it possible to embed and nest multiple components into a single server page. This helps to isolate data that needs to be updated, and allows different DSP instances to be assigned to a container dynamically. For more information, see DspContainer.

  • Well-formed HTML layouts with ID-based binding to data and logic.

    Fields in the component structure are represented by HTML elements in the layout. Each element has an id attribute that identifies the field that it is bound to.

  • Client-side syntax-checking. For more information, see Syntax Checking in Dynamic Server Pages .

Runtime Considerations

When the Uniface Server first receives a request for a dynamic server page, it generates an HTML document based on the component definitions and sends it to the browser. The first time the complete page is generated, this includes references to the JavaScript files required for the Uniface runtime engine, and CSS files required for formatting the page, as well as the layout. The JavaScript commands initiate the communication process between the client and server side of the DSP. The data that is then passed between the client and server consists of JSON streams containing the entity, occurrence, and field definitions, and their data.

The header of the HTML document, which is sent to the client as part of a full page load, contains a set of links and script tags that reference CSS and JavaScript files, which are typically located in the webapps/uniface directory. The set of JavaScript and CSS files that is referenced is determined by the logical widgets used in the component, and the physical widgets to which they are mapped.

Note:  For dynamic server pages to work, JavaScript must be enabled in the browser. In some browser-operating system configurations (such as Internet Explorer 8 running on Windows Server 2008), this may still result in security warnings. In this case, you need to add the providers of these JavaScript files (such as Uniface and mobile plug-in APIs) as trusted providers.

The order in which CSS and JavaScript files are loaded is determined by their location in the layout. You may want to add your own set of files, which have dependencies on the Uniface files. In this case you need to control the load order. To do so, you need to define a placeholder for Uniface JS and CSS in the layout. This ensures that the Uniface Javascript and CSS is loaded precisely when required. For more information, see Controlling the Load Order of JavaScript and CSS .

Logical to physical widget mappings are configurable. By default, Uniface maps to HTML 5 elements, but you can switch this to use JavaScript-based web widgets. You can configure these mappings using the usys.ini file. For more information, see Continuing to Use Dojo Widgets for DSPs.

Related Topics