Mixin for qx.io.remote.Rpc

[panyasan]

Hello,

a few days ago, we were discussing about the separation between client and
server and the separate testing of both components of a web application.
Thomas suggested that a transport should be written which retrieves static
data from a local file instead of a server.

Here is my quick-and-dirty suggestion to implement such a transport, a new
mixin in the RpcConsole contribution:

http://m53s12.vlinux.de/cboulanger/RpcConsole/trunk/demo/default/api/#rpcconsole.MRpcMockup

The API viewer has all the information, but here it is again:

A mixin for qx.io.remote.Rpc which allows to prepare code relying on a
json-rpc backend to work with static mockup data independently of the
server. This allows to develop client and server independently and to create
static demos.

For the mixin to work, you need to patch qx.io.remote.Rpc like so:

qx.Class.patch( qx.io.remote.Rpc, rpcconsole.MRpcMockup );

The mixin works in three modes, controlled by a new “mockupMode” property of
a qx.io.remote.Rpc instance:

   1. “off”: no effect, qx.io.remote.Rpc works normally
   2. “monitor”: qx.io.remote.Rpc works normally, but for each request, the
mixin opens a browser window with json data to store in a file. The window
contains instructions where to save this file.
   3. “on”: instead of sending the request to the server, the mixin
retrieves the content of the file that has been created with the information
of the monitor mode (2).

This mixin requires the use of the “Crypto” contribution, which you can
include by adding

{
  "manifest" : "contrib://Crypto/trunk/Manifest.json"
}

to the “libraries” key in your config.json file.

The mixin works by overriding the _callInternal method of qx.io.remote.Rpc,
this is why it is neccessary to use qx.Class.patch() instead of
qx.Class.include().

The idea is that the mixin helps you create static files from real valid
responses of your server, so you don't have to write all this json yourself.
The name of the files are sha1 hashes created from the service name/method
and the parameters, so each request should have a unique file name. The
files are stored in the resource/mockup folder.

My first tests are satisfactory, but of course, more testing is required.

Cheers,

Christian
--
View this message in context: http://n2.nabble.com/Mixin-for-qx-io-remote-Rpc-tp3966570p3966570.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

[panyasan]

Forgot to add that I have updated the RpcConsole demo to showcase the
MRpcMockup:

http://www.qxtransformer.org/qooxdoo/RpcConsole/trunk/demo/default/build/

Obviously, the "On" mode doesn't work since I have not saved the rpc
responses to script/mockup.


panyasan wrote:

>
> Hello,
>
> a few days ago, we were discussing about the separation between client and
> server and the separate testing of both components of a web application.
> Thomas suggested that a transport should be written which retrieves static
> data from a local file instead of a server.
>
> Here is my quick-and-dirty suggestion to implement such a transport, a new
> mixin in the RpcConsole contribution:
>
> http://m53s12.vlinux.de/cboulanger/RpcConsole/trunk/demo/default/api/#rpcconsole.MRpcMockup
>
> The API viewer has all the information, but here it is again:
>
> A mixin for qx.io.remote.Rpc which allows to prepare code relying on a
> json-rpc backend to work with static mockup data independently of the
> server. This allows to develop client and server independently and to
> create static demos.
>
> For the mixin to work, you need to patch qx.io.remote.Rpc like so:
>
> qx.Class.patch( qx.io.remote.Rpc, rpcconsole.MRpcMockup );
>
> The mixin works in three modes, controlled by a new “mockupMode” property
> of a qx.io.remote.Rpc instance:
>
>    1. “off”: no effect, qx.io.remote.Rpc works normally
>    2. “monitor”: qx.io.remote.Rpc works normally, but for each request,
> the mixin opens a browser window with json data to store in a file. The
> window contains instructions where to save this file.
>    3. “on”: instead of sending the request to the server, the mixin
> retrieves the content of the file that has been created with the
> information of the monitor mode (2).
>
> This mixin requires the use of the “Crypto” contribution, which you can
> include by adding
>
> {
>   "manifest" : "contrib://Crypto/trunk/Manifest.json"
> }
>
> to the “libraries” key in your config.json file.
>
> The mixin works by overriding the _callInternal method of
> qx.io.remote.Rpc, this is why it is neccessary to use qx.Class.patch()
> instead of qx.Class.include().
>
> The idea is that the mixin helps you create static files from real valid
> responses of your server, so you don't have to write all this json
> yourself. The name of the files are sha1 hashes created from the service
> name/method and the parameters, so each request should have a unique file
> name. The files are stored in the resource/mockup folder.
>
> My first tests are satisfactory, but of course, more testing is required.
>
> Cheers,
>
> Christian
>

--
View this message in context: http://n2.nabble.com/Mixin-for-qx-io-remote-Rpc-tp3966570p3971979.html
Sent from the qooxdoo mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel