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 [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
