Command Level Virtualization ('Empty Client')

Visual WebGui virtualizes the application state from the server to the client using a unique protocol of events and commands.
Think of a bitmap based virtualization solution such as Citrix or Remote-desktop, even though highly optimized it is still transferring a picture; the client plays the minor part of showing a bitmap and replacing it when necessary.

Now, the natural evolving paradigm would be having the client “understand” better in terms of UI yet having the application perform the business logic and manage sensitive data on the server. Visual WebGui is able to utilize the client strength and at the same time leverage the accessibility to data and the server's security.

Visual WebGui Pipeline Balance Flow

Visual WebGui pipeline is balanced and based on the following principles:

• The client gets the kernel code only once – then it’s cached and reused.
• Events are sent to the server only when necessary
  • Events that are not handled by the server are queued on the client.
  • A mechanism of unique events prevent sending multiple events which are causing a single result (for example, only the last text within a textbox is sent to the server as long as the “KeyPress” event is not handled by the application)
  • Event and command sizes are limited to 1kb and never exceed the HTTP packet size.
• The server gets the last event queue, and then it executes the applications logic according to the events which are executed chronologically.
• As a result, the current application instance might change the UI accordingly then minimal commands are sent back to the client kernel in order to cause the client to render the relevant parts of the UI and add/remove/change data.

 

Client Kernel Structure

XSLT - Visual WebGui uses client rendering capabilities as offered by the target device, therefore, when using a plain HTML device (i.e. web browsers) the best choice was to utilize XSL transformation in order to perform client side HTML rendering. Each of the Visual WebGui controls and general layout behaviors and capabilities such as Dialogs, Docking, and Anchoring etc. are represented in XSLT.

When sent to the client, one large XSLT is created of all the XSLT parts of controls and general purpose by two mechanisms which are part of Visual WebGui core library called “Collectors” and “Compiler”. The static XSLT is then cached on the client and enables any further render of the UI (either partial or full UI elements rendering).

JavaScript – as mentioned before, the client behavior in the HTML presentation layer is performed by JavaScript code. Each of the controls in Visual WebGui has its own JavaScript piece of code and also many general behaviors such as:

• Dialog layers management
• AJAX communication with the server
• Drag & Drop mechanisms
• General events handling
• Events optimizing and queuing

The “Collectors” mechanism is collecting all the JavaScript files into one large file and then the “Compiler” rearranges and compresses this part of the kernel in order to create a highly optimized kernel part.
This compressing mechanism can be turned off in case we need to debug client side scripting, this is done by switching the “DisableObscuring_Switch” on (0-Off, 1-On):

Note: it is strongly recommended to switch this switch back on when deploying the application.

CSS – is the part which is responsible for general styling and exists in most of the controls and in some general scope styling mechanisms.

Static Resources

The static resources mechanism enables the system to cache the entire set of resources (JavaScript, CSS, XSLT and any other static images or data of any kind) of the application as static cached files within the web server’s directory.

Switching Static Resources to “On” can be done either through the web.config file or through the project properties and results in caching of the entire resources and further optimize those resources at runtime.

Note: it is strongly recommended to develop with this flag off and deploy with this flag on.

Private Version

The private version is a value which helps Visual WebGui decides whether it should grab new resources from the server dynamically or it can use the old cached ones. When upgrading a version successfully, the internal cache version is changed within the core library automatically; therefore, this value should not change in this case. However, when changing resources as part of the development process (I.e. creating themes or custom controls) this value should be advanced whenever a change is made in order to cause Visual WebGui to retrieve a new version of resources and avoid using old cached files.

Changing Private Version value can be done either through the web.config file or through the project properties:

Icons Preloading

As part of the general optimization of resource management, Visual WebGui offers a mechanism for preloading icons when the client first approaches the server.
Switching Icons Preloading to “On” can be done either through the web.config file or through the project properties and results in loading and caching icons on the client machine when it first approaches the application. 

Note: using this flag is application dependent; in case the application contains a very large number of icons and many of them are inaccessible for some users, there is no point in preloading all of them since some of them are not used. In any other case, switching the Icons Preloading to “On” will cause a slight latency on first access, however, will result in better performance from this point on since images are now cached on the client.

Inline Windows

Visual WebGui implements 2 different approaches for handling windows:

1. Non-inline windows – Internet Explorer (IE) dialogs based – which are separate windows of the Internet Explorer.
2. Inline windows – dialogs which are drawn using floating div elements within the client area of the browser.

When using non-IE browser, the default behavior will always be Inline-Windows, and with IE the default would be Non-inline windows, unless configured otherwise:

Setting inline windows switch to “On”, either through the web.config file or through the project properties forces the use of Inline-Windows in IE as well.

Behaviors differences:
Naturally, inline windows are limited to the client area of the browser, therefore, they do not appear in the task bar when minimized or managed as normal OS windows. Except for that there should be no difference in using those windows type.
Inline-Windows are fully customizable in terms of looks and behaviors as they are entirely drawn and controlled by the client code and not affected by any browser dialog management.

G-Zip Compression

In addition to the internal compressed mode of the client kernel code, a G-Zip compression mode can be applied either through the web.config file or through the project properties:

Conclusion

Visual WebGui Virtualization model: the static client kernel and the server are constantly balancing each other. The client sends events to the server and in return, the server sends update commands back to the client. The client is responsible to re-render the UI when needed.

Kernel parts are assembled of plain HTTP formats: XSLT, JavaScript & CSS and are compressed to the minimal size of ~200kb. There are some customizable switches which are tuning this process, the cache level and enables optimizing for the various usages. 

Next >>