DSP JS API function:
Putting application developers in control of the presentation layer
HTML5 already provides a powerful set of form controls out of the box, and its functionality is continuing to grow and mature. To get access to all that functionality, application developers need to be able to interface directly with the controls. Uniface 10.3 Dynamic Server Pages provides exactly that capability.
Before we go into detail, let’s see how Uniface’s support for web technology has evolved over time to give developers more and more control over their applications.
The beginning: Uniface Server Pages
Uniface 7.2 provided our first functionality for the web: The Static Server Page, also known as the Uniface Server Page (USP). USPs enable binding between the Uniface server-side data structure and an HTML client side. They handle communication between client and server in a very simple way: the server generates an HTML page complete with data substituted into the HTML, and the browser simply displays that HTML page.
Updates are initiated by the browser via a standard HTML submit, after which the server will load the updates and reconnect them with the back end. After that, the server again generates a full-page response with all changes handled, and the whole process starts again from the beginning.
A leap forward: Dynamic Server Pages
Uniface 9.4 introduced the Dynamic Server Page (DSP) allowing Uniface developers to create rich internet applications (RIAs). The biggest difference between a USP and a DSP is the absence of full-page refreshes in the DSP. Obviously, data is still sent to the server and received back by the client, but instead of the whole page being refreshed, only the affected data is returned and merged into the page displayed in the browser. All communication is handled by the Uniface DSP and programming is as easy as writing some ProcScript in a trigger.
In addition, Uniface 9.4 DSPs provide out-of-the-box client-side syntax checking, which, in case of a syntax error, avoids a round trip to the server. A DSP consists of a server part and a client part. The client part has a copy of the component definition, which is what allows the client to perform syntax checking.
Introducing the ability to manipulate client data
Initially, Uniface application developers could write business logic solely for the server, using ProcScript; the client side was closed to them.
Application developers take charge of the presentation layer
With Uniface 10.3, we have now also opened up the presentation layer of the client: the Document Object Model (DOM) layer. Using a simple function, a Uniface data object can now get a reference to its bound element in the DOM layer, allowing Uniface developers to access DOM elements in the context of that field, its occurrences, and its instance. The function is:
From the bound DOM element, it is possible to navigate to sibling and parent elements. In case of an AttributesOnly field, the same technique can be used to navigate to child elements. This gives Uniface developers full control of the DOM, allowing integration of third-party JS libraries that integrate at DOM level.
In the following code example we will use the new JS function to change the default reporting of client side syntax errors.
The webtrigger onSyntaxError is the trigger that gets fired the moment the client encounters a syntax error. The default way for Uniface to respond in this situation is to set an error class on the element bound to the field that is in error. CSS would then style it appropriately. The code below overwrites the default behavior and sets the error class to the parent element of the element bound to the field:
The getBouldElement() function is simple to use and provides full access to the DOM layer of the browser. It opens up communication with any JS technology that needs to interface on the presentation layer.