Introduction

Although NavWin MVP uses ASP.NET on the server side, it uses Google Web Toolkit on the client side. The communication with this powerful AJAX layer is handled using standard remote callbacks. This provides a simple way for the client (the web browser) to communicate information to the server (ASP.NET) using simply Unicode encoded strings.

This web page describes the format of the strings.

Location Token in the URL

The location token is encoded into the URL hash fragment (#fragment). A URL has the following format

Webaddress
Webaddress?querystring#fragment
Webaddress#fragment

We use the #fragment to encode the current URL location. However one very important thing to understand is that the #fragment is never sent from the client to the server. This is a client side only concept and is meant to be used for client side only processing. However we need it on the server also for our MVP system. Therefore, whenever we send a message from the client to the server we embed the #fragment in the message. This is referred to as the <Location Token> below.

Location Token Structure

The location token has the following structure:

This is all the information that is needed by the server to identify which view the user is trying to access. Here is an example:

#SSLPortal&EditLink&2&Barclays@ModelSSLPortal

The breakdown is as follows:

Application ID = SSLPortal (this allows the server to quickly identify which application has the correct presenter)

Presenter ID = EditLink (this tells the application which presenter to use)

Presenter Argument 1 = 2 (this is the unique object ID in this case)

Presenter Argument 2 = Barclays (this is a text description of the previous argument to help the user understand when they get a message object 2 is no longer found, in fact becomes object 2 ‘Barclays’ is no longer found).

Model ID = ModelSSLPortal (The model only needs to be sent when dealing with local storage – This is basically the unique key to access the correct local storage data for the given presenter).

Local Storage

There is an HTML5 concept called local storage which is supported by all major browsers. This is a very powerful new concept, that is very similar to a cookie, in the sense that it is stored on the client PC and you access it as a name/value pair, but it is also different as there is no limitation on the size of the data and it is never sent back to the server (unless the client explicitly does this somehow). Local storage makes it possible for users to use the web apps without having to log into any server account (e.g. as a trial version). The disadvantage for the user is that their data is only available on one computer

Client to Server Messages

LOAD Messages

These messages are fired from the client after the basic client page HTML has finished loading

Message	Description
“+LOAD”	This message will be sent if you type in the basic web URL https://www.navwin.com/webapps.aspx. The presenter logic will send you to the default web app presenter (App Selector in this case)
<Location Token> ” +LOAD”	This message is sent from the client and you are using server data
<Location Token> ” +LOAD+”+<Local Storage Data>	This message is sent from the client and you are using local storage

EVENT Message

The event message is sent when the user does something on the client (such as click a button). The event is processed by the presenter logic and will result in one of three things

1) The current presenter is updated

2) A new presenter or view is loaded

Message

Description

<Location Token> “+ EVENT @” <Event Data> ”@” <Control Data>

This message is sent from the client and you are using server data.

<Location Token> “+ EVENT @” <Event Data> ”@” <Control Data> ”+” <Local Storage Data>

This message is sent from the client and you are using local storage. As above, it is sent

Server to Client Messages

The server sends message back to the client in response to the above two client messages. The LOAD message is always replied to using an ADD message. The EVENT message is always replied to using an UPDATE, URL or BACKURL message.

Message	Description
“ADD@”<Control layout and data>”	This message contains the control layout information and the initial control data.
“ADD@”< Control layout and data>”+”<Local Storage Data>	As above, but also includes the model data that needs to be stored on the client
“UPDATE@”<Control update data>”	This message is sent in order to control data currently displayed on the client. The control layout is not changed, but control properties (such as font colours) can be changed.
“UPDATE@”<Control data>”+”<Local Storage Data>	As above, but also includes the model data that needs to be stored on the client
“URL@”<Fully formed URL>	This tells the client to change location. The location token is embedded in the URL also as a #fragement
“URL@”<Fully formed URL>”+”<Local Storage Data>	As above, but also includes the model data that needs to be stored on the client
“BACKURL”	Tells the client to go back one level using the client history
“BACKURL+”<Local Storage Data>	As above, but also includes the model data that needs to be stored on the client