IBM Web Experience Factory 8.0 Anatomy of a Client-Side Application

Anatomy of a Client-Side Mobile Application

A Web Experience Factory Client-Side Mobile Application makes use of REST/JSON calls to the server to perform operations, and then processes the result data into the client page(s), performing page transitions within the client browser runtime, without having to serve up additional application pages from the server.

The following describes the terminology for the high-level client-side application components and is followed by a Client-Side Application high-level overview diagram.

Aggregator Page The aggregator page is the initial server side page that is loaded when a client-side application is run. There is a single aggregator page for each model, which contains the client-side initialization code, and optionally the client HTML templates. This page is used as a container for rendering all of the client side HTML pages. When a client side page is constructed it is inserted into the aggregator page and made visible. The aggregator page is specified in the Client Application builder, and can be customized with HTML markup to meet your requirements. Web Experience Factory ships with a few different aggregator page layouts, which are located in the WebContent\factory\pages\client directory. these files are client_app.html, dojo_client_app.html, and dojo_mobile_tablet_layout.html

Client Runtime The client runtime is made up of several JavaScript classes that functions as a Model-View-Control for the client runtime. This controller contains the application variables (data), client templates, JavaScript actions and methods. The client runtime also handles the processing of client-side actions, events, fetching REST service data, and processing of page content. The main JavaScript instance that provides the overall control is the WebAppAccess class. A unique instance of this class is constructed to avoid collisions when run in a Portal environment where mulpitle instances are used on a single portal page. In custom JavaScript code (Client JavaScript Method) you can reference the unique WebAppAccess instance by using the "this" reference. For example: var id = this.getVariable("ordersGetOneOrderInputs.ORDER_ID");

HTML Client Template The HTML Client Templates are constructed from client pages in the model, and contain JavaScript code and place holders where data will be substituted when a client page is processed. The results of the processed template is a client page.

Here is an example fragment from a Dojo Mobile List Template


Client Page A Client Page is HTML markup, CSS, and JavaScript that is constructed entirely on the client (Browser) using a HTML Client Template, and JSON data.\\ The resulting client page is inserted into the aggregator page where it is then made visible. Typically any previously visible page is then hidden.\\ Is some cases, such as the Dojo Mobile iPad layout multiple client pages are visible at the same time.

Application Data The application data is managed my the client runtime and contains all the client Variables for the application. This includes data such as service results , service inputs, loop variables, etc.... During requests to the server client variables can be selectively updated based on their changed value setting.\\ The Variable data is stored in JSON in the client and can be access as an indirect reference from the Designer pickers, or from JavaScript (Client JavaScript Method) using the "this" reference.\\ For example: var id = this.getVariable('ordersGetOneOrderResults.Row.EMAIL'); will fetch the EMAIL of the ordersGetOneOrderResults Variable.
Where the Variable looks similar to this:



Server Runtime In a client-side application the WEF Server Runtime provides many of the same is features that it does for server-side applications. There are some differences to allow the client accesses these server-side features.\\ The server runtime will handle REST Services requests from the client application and return the results a JSON data.\\ Form submits are processed by the server-side runtime, and any resulting validation errors are returned as JSON to the client for display.\\ Pages are processed by the JSP processor, but the result is a HTML Client Template, which is sent to the client once where it is cached.\\ Any Client versions of Variables, Methods, Actions, Events will also be delivered to the client. In many cases this information sent to the client in the initial Aggregator Page load.

Client-Side Application high-level overview diagram.

High-level flow for client-side list and details

The following describes the high-level flow of a client-side list and details application.

Step 1 The initial page load combines client page template with JSON data to construct list page HTML.
Once the list page is constructed it is then made visible.


Step 2 When a list item is selected the JSON data for the selected row is fetched from a server REST service.
In a hidden area of the page the JSON data is combined with the client page template to construct details page HTML.


Step 3 Once the details page construction is complete it is then made visible, and the list page is hidden.
The visibility process can be instantaneous, or can use a Dojo CSS transition to slide in the details as the list slides out of view.

Dojo Mobile

Dojo Mobile is a lightweight subset of the Dojo Toolkit, targeted at developing rich native looking user interfaces for mobile devices
( [http://dojotoolkit.org/features/mobile] ). It provides both animated page transitions between multiple sub-pages in a single outer HTML page (Dojo Mobile View transitions) and rich UI controls (eg, mobile switches, sliders, checkboxes and radio buttons) suitable for use on mobile devices (lighter weight than the full blown Dojo toolkit UI control widgets).

The Web Experience Factory Client-Side Application support automates use of both Dojo Mobile views (eg, dojox.mobile.ScrollableView) and animated view transitions for client pages, and the use of Dojo Mobile UI controls (eg, dojox.mobile.Switch) via Dojo Mobile specific Rich Data Definition settings.

• Dojo Mobile Theme client_dojo_mobile.uitheme - specifies base template pages for use by Client View and Form, that leverage dojox.mobile.ScrollableView for the client pages generated by that builder, tells the Client Application support to use the lighter weight dojox.mobile.parser (as opposed to dojo.parser) and sets the default rich data definition file to dojox_mobile_datadef.xml.
•  
• Dojo Mobile (dojox.mobile) Data Definition dojox_mobile_datadef.xml, specified in the Dojo Mobile theme specifies use of dojox.mobile based UI controls for various data types such as text input, checkbox, radio buttons, and defines an optional switch data type that leverages the dojox.mobile.Switch control.

Dojo Mobile and Data layout templates

The following data layout templates are provided to apply a Dojo Mobile look and feel to your list pages, and custom data layouts may be created by developers.

• dojo_mobile_edgetoedgelist.html
• dojo_mobile_multiline_edgetoedgelist.html
• dojo_mobile_roundrectlist.html

NOTE:  Unlike server-side application data layouts, where you often need to specify a style for each layout item in the Data Layout builder,  Dojo Mobile layouts are typically styled by Dojo Mobile itself and thus you may often leave the "Style" column blank for the Data Layout elements when using Dojo Mobile based data layouts.

The following data layout templates are provided to apply a Dojo Mobile look and feel to Client Page Navigation generated pages.

• dojo_mobile_navigation_list_template.html
• dojo_mobile_navigation_segmented_tabs_template.html
• dojo_mobile_navigation_tabs_template.html

Differences from a hand-coded Dojo Mobile application

For those familiar with or reading documentation on how to manually develop a Dojo Mobile (dojox.mobile) web application, here are a couple of subtle differences between hand coding a Dojo Mobile app according to the dojotoolkit.org website documentation, and use of Dojo Mobile views in a Web Experience Factory Client Side Application.

• Dojo Mobile hand-coded applications tend to have an explicit moveTo attribute specified on each UI navigation control (eg, view back button or list item) to specify which page to go to next, and then actions/operations tend to be executed as a result of an event handler running on view transition.
• Web Experience Factory applications (both servier-side and client-side) typically execute an action on UI control trigger and then the action determines which page (view) to transition to, based on the results of that action logic (eg, server side validation or operation success). The integration of Dojo Mobile view transitions within the Web Experience Factory Client Side runtime, thus uses WEF Client Side actions (Javascript based) and then Dojo Mobile Javascript APIs to trigger the view (client page) transitions, rather than using the "moveTo" attributes on the various Dojo Mobile views and UI controls.

Note: Web Experience Factory, as of version 7.0.1 and later, provides automation for server-page based mobile web applications, that may optionally use Dojo (and unfortunately include a data definition file named dojo_mobile_datadef.xml). That earlier server-page based mobile support includes optional full-blown Dojo toolkit usage, and not what is referred to as "Dojo Mobile" in the above Client-Side Application support which is based on the Dojo toolkit's lighter weight, mobile specific dojox.mobile.\* based extensions._

Note: Since the Client-Side Application support in this release is targeted solely at mobile devices, if you must build a single multi-channel model that supports both desktop and mobile devices (via profiling), the server-side page based mobile development support available in Web Experience Factory 7.0.1 may be more suitable for such development.