Limax Project

5.5 Client development

5.5.1 Javascript client

The previous examples have involved in the javascript development. Here only clarify the client namespace's organization mode

Contrasted to the template.js, all the datum of the client are organized in the tree with the ctx as the root. In the examples above, using the console.log(ctx) in the proper position could output this tree. We will clarify it layer by layer below.
- The first layer
  
  100, is the PVID of the current request service. If one client has more than one request service, multiple PVID will be parallel list here.
  
  f: -1, the status flag returned by the auany, which is related to the authentication module.
  
  i: 57344, the SessionId of the user.
  
  onclose，onerror，onopen, the handle of the network message set in the template.js.
  
  register, the function is injected by the system. If the view has many fields and need to monitor the change in the individual fields separately, the register function could be used. There are three parameters: r is the view object; v is the field's name which need to be monitored; f is the monitor. The interpretation of the parameters is similar to the onchange.
  
  send, the function is injected by the system, and is used to send the control message to the server. There are two parameters: r is the view object; s is the message string which need to be sent.
- The second layer
  
  Here you can see the three Views organized according to the namespace described in the xml of the server.
  
  Check the example.share.xml:
  
  example.share.html
```
<namespace name="share" pvid="100">
```
  Here you can see that the share and pvid=100 are parallel. Why a special layer is divided here?
  
  The reason is that the client framework allows to connect to multiple services in the same operation system, which means connecting multiple sets of the projects defined by the xml. So there is no guarantee that two projects have not use the same outermost namespace and only PVID could correctly distinguish.
- The third layer
  
  This layer need to be interpreted in two groups: one group includes the GlobalView and SessionView; the other includes the TemporayView.
  
  The GlobalView and the SessionView:
  
  The perspective to the SessionView is different between the endpoint and the server. An endpoint has only one Session, and should be equally treated just like the GlobalView, considered from the endpoint. The MySessionView is used to explain.
  
  __c__: 1, this is the unique number of the View provided when generating the source code for the server.
  
  __n__: "share.MySessionView", is the name of the View.
  
  __p__: pvid, is used to record since the View has no similar field as _parent_ to reference back to the top layer.
  
  onchange: the monitor injected by the template.js to this view.
  
  var0: the field defined by this view.
  
  It should be noted that the field defined in the xml description may not be existed, either not be initiated, or be removed.
  
  The TemporayView:
  
  1: Object， the number 1 is the instanceid of the temporay view. A temporay view allows multiple instances and is distinguished here.
  
  __c__, __n__, __p__, the same as the above.
  
  onchange: the monitor template injected by the template.js to this view.
  
  onopen: is called when the server notifies that the temporary view is created. The first parameter is the instanceid of the temporary view, and the second parameter is the sessionid array of the the current temporary view's members. The onchange function is reference copied to the instance of the temporay view created.
  
  onattach: is called when the new member is added into the temporary view. The first parameter is the instanceid of the temporary view, and the second parameter is the sessionid of the new member.
  
  ondetach: is called when the member leaves the temporary view. The first parameter is the instanceid of the temporary view, and the second parameter is the sessionid of the leaving member, and the third parameter is the leaving reason.
  
  onclose: is called when the server closes the temporary view. The parameter is the instanceid of the temporary view.
- The forth layer
  
  Unfold the instance of the temporay view and enter the forth layer.
  
  57344: Object, is the subscribed information of the user sessionid=57344. If the temporay view has multiple users added, the multiple objects will be list parallel. Refer to the figure 2 in the experiment 7 above for the detailed information.
  
  __i__: 1, represents the instanceid = 1.
  
  __c__, __n__, __p__, the same as above.
  
  onchange: the onchange copied when onopen.
  
  The variable and bind fields defined by the temporary view are in this layer. Here you can see that the server does not create them.
- The fifth layer
  
  Unfold the subscribed information of the user sessionid=57344 of the temporay view.
  
  The subscribed field _var0 is "onAttached 57344" for the user sessionid=57344.
- Some explanations
  1. Through analyzing the source cod of the template.js, the conclusion could be drawn that the global view and session view have been created before the ctx.open is executed, and wait for the notification of the data change from the server; only a template of the temporary view is created before the ctx.open is executed, and the actual instance of the temporay view will be created when the onopen of the template is called and attached on the template distinguished by the instanceid.
  
  2. The e.sessionid of the onchange message (e) is a little special. Except for using the sessionid of the changed member when notifying that the subscribed field of the temporay view has changed, the sessionid of the current user is also used. Refer to the line 2 of the figure 2 in the experiment 7 for the detailed information.
  
  3. The field of the global view and session view could be identified as:
```
ctx[pvid].path_to_view.fieldname
```
  The variable and bind field of the temporay view could be identified as:
```
ctx[pvid].path_to_view[instanceid].fieldname
```
  The subscribe field of the temporary view could be identified as:
```
ctx[pvid].path_to_view[instanceid][sessionid].fieldname
```
  The path_to_view above could be explained as the path name from the namespace to the view, referrenced by the manager element in the service element described in the xml, through state element.
  
  4. Design the javascript client, and avoid naming the field of the view with the onXXX and __XXX__ when defining avoid the conflict.

5.5.2 The simplest server

In order to try the implementation of the clients behind, a simplest server which could adequatly explain the problems is provided here, including the chrome demo for the contrast.

Clear all the modification in the previous experiment, then:

MySessionView.java

private MySessionView(SessionView.CreateParameter param) {
    super(param);
    // bind here
    long sessionid = param.getSessionId();
    setVar0("Hello " + sessionid);
    MyTemporaryView.createInstance().getMembership().add(sessionid);
}

protected void onControl(_MySessionView.control param, long sessionid) {
    onMessage(Integer.toString(param.var0), sessionid);
}

protected void onMessage(String message, long sessionid) {
    setVar0(message);
}

example.html

v100.share.MyTemporaryView.onopen = function(instanceid, memberids) {
    this[instanceid].onchange = this.onchange;
    console.log("v100.share.MyTemporaryView.onopen", this[instanceid], instanceid, memberids);
    ctx.send(v100.share.MySessionView, "99999");
}

Take note of the last statement "ctx.send(v100.share.MySessionView, "99999")" which sends a control to trigger a change operation when temporary view onopen.

Prev Next

5.5 Client development

5.5.1 Javascript client

5.5.2 The simplest server