Introduction
As the NavWin MVP system relies on all the processing done
on the server side, we define a compact way to transfer arbitrary control
definition data to the client and back again. The notation is similar to JSON
but even more compact. The primary difference is the use of the <fixed
value> concept which allows the client and server to take advantage of the
sequence of processing the message, in order to reduce the amount of
information sent. Apart from that, the notations provide for similar object
structures.
The compact control notation is defined below.
Message definitions
Definition of <object>
This is used for communicating screen layout and data
between the client and the server
<object> = <type>@<id>@<object
attributes> @
<object attributes> = {<fixed
value>}{<item>}
<fixed value> = <value>@
<Item> = <named attribute> | <object> |
< list of object >
<named attribute> = <attribute
name>@<value>@
<list of object> = <attribute
name>@<count>{< object attributes>@}
Method of parsing
The messages are passed from left to right, and by
recursively calling a ‘create object’ function as needed:
1. Split
the message into a string array, by splitting on the ‘@’ character.
2. The
object <type> is extracted first in order to send the message to the
correct object handler.
3. The
<id> is then extracted so that the object can be globally accessed as
required (from a lookup dictionary). The object type determines the fixed
attributes to be read, if any.
4. Next
we will read any fixed values. The values need to be processed to convert ‘/1’
and ‘/2’ into their relevant values.
5. Next
we will read one of the following
a. An
empty field, signifying the end of the object, in the message this will appear
as @@ but note that @@ can appear in other circumstances.
b. An
object optional attribute name (can be looked up from a list of all supported
object attributes), in which case we can process the relevant object attribute
value, as for fixed values,
c. A
list of objects name (can be looked up from the list of all supported lists).
Note that the value <count> determines the exact number of items in the
following list. If the number of list items is more or less than <count>
then the message cannot be parsed.
d. An
object type (if the value is not one of the above then it is either an object
type or an error), we pass the message to the object handler (recursively) and
this will either find the object type or raise an error.
Examples of usage
Sending a text box
TextBox@txtStockName@FTSE@width@20@@
Sending a panel (with two embedded objects)
Panel@pnlAddPanel@
TextBox@txtStockName@FTSE@width@20@@
Button@btnAddStock@Add@@
@
Example of a grid (with embedded lists)
This grid has two rows. Each row is an object so it is
terminated with an empty @ field. Each cell is also an object so they are also
terminated by an empty @ symbol. We have an attribute ‘font@bold@’ on one cell
to indicate this has bold font.
FlexGrid@grdGrid@title@My Grid@rows@2@
cells@4@ColA@@ColB@@ColC@@ColD@@@
cells@4@Cell1@@Cell2@@Cell3@font@bold@@Cell4@@@
@