JSRMI (Javascript Remote Method Invocation) is a portable browser-neutral Javascript library that makes it possible to execute -Javascript functions in a browser from a process external to the browser.
-JSRMI is not in any way tied to Java's RMI, but provides a similar mechanism. JSRMI is completely decoupled from the core Selenium Javascript API, but it can -be used to access the Selenium API from outside the browser.
-All of the -browser-side JSRMI code resides in the rmi.js script - available in the Selenium -distribution.
-Libraries for other languages are under way.
-Just include the jsrmi script in your own:
-require "jsrmi"
-
-browser = Selenium::Browser.new.proxy
-someArea = browser.document.getElementById("someArea")
-someArea.value = "Hello from Ruby #{Time.new}"
This will modify the text of a text area in the browser. Looks strangely -familiar to Javascript doesn't it? You can of course call the selenium API too -if the browser has loaded the main Selenium page (which also includes the rmi.js -script - at least that is the plan - I hope (Aslak)).
-(You can safely skip this section if you don't care - this is gory details)
-The rmi.js script uses the - -XMLHttpRequest object (available in all compatible browsers) to communicate -with the external process. It executes a GET-POST loop which is repeated ad -infinitum - pulling JSRMI invocations from the external process with GET and -POSTing the results back. This all happens in a separate thread, thereby having -minimal impact on the rest of the web page - without causing a page refresh.
-The rmi.js script will do a HTTP GET to a URL on the same host/port as the rmi.js -script was loaded from. The content returned from the GET (which must comply -with the JSRMI protocol) is then translated into -Javascript and dynamically executed via Javascript's -eval() function.
-The result of the function call (typically a Javascript object) is translated -back into the JSRMI protocol format and POSTed back to the same URL as the GET.
-The external process typically consists of a library that embeds the -following functionality:
-A local invocation should translate the invocation to a JSRMI protocol string -and put it on the output queue (which jsrmi will GET). It should then wait for -the result of the browser side invocation to be put back on the input queue via -a POST from jsrmi. Finally it should translate the return value (another JSRMI -protocol string) into a native object and return it to the caller.
-At any given point in time there should only be one single JSRMI protocol -string in one of the queues - depending on the where the invocation is in its -lifecycle.
-JSRMI allows objects (such as browser side HTMLDocument, HTMLTextField etc) -to be transferred back and forth. This is based on a simple mechanism where each -object is given a unique id and maintained in a pool on each side. this pool is -used to reference and dereference native objects back and forth from the JSRMI -protocol strings.
-The Selenium browser runtime will load both selenium test scripts and the web -pages from the web application you're testing into the browser. Modern browsers -don't allow content to be loaded from different hosts (cross browsing security -restrictions). A web application being tested will typically be deployed on a -server, and therefore the selenium test scripts must be loaded from the same web -server. Depending on who's writing the Selenium scripts and executing them, this -may or may not be a restriction to its usage.
-Under some circumstances it is desirable to keep Selenium test scripts on -your local machine (the same as the one running the browser with the Selenium -runtime) rather than on a remote web server hosting the web application being -tested. Some examples are:
-It is important to emphasise that hosting the Selenium scripts on a local -machine would also require that the browser loads the web site being tested from -the local machine. Aren't we creating new problems by requiring testers to -install a full web server environment on their machines? Actually no. The JSRMI -libraries in Ruby and Java (and those who may follow) will soon provide a light -HTTP proxy server. The local browser will load the remote web site through this -HTTP proxy. The browser's security restrictions are satisfied since all content -(Selenium runtime, Selenium scripts and the remote website) is loaded through -localhost.
-Think of all boring web form tasks you could automate with JSRMI....
-TODO: describe the format.
-Start by understand the inner workings - look at the ruby implementation and -study the javascript. (When the JSRMI protocol is better described, studying -this code should not be necessary).
-It will be to implement a JSRMI client -library in a dynamic language than a static language, because dynamic languages -allow arbitrary messages (method invocations) to be sent to an object. Most -dynamic languages (Ruby, Python, Groovy, Smalltalk) have a generic mechanism to -intercept any message and an object message->JSRMI protocol translation logic is -trivial to implement based on this.
-JSRMI clients for static languages such as Java or C# will either have to -choose a subset of the Javascript functions and objects that you want to access, -or implement some generic invocation mechanism that allows raw JSRMI protocol -strings.
-The former is more easy to use from a user perspective, but will be -restricted in terms of flexibility. The latter is completely generic, but -awkward to deal with from a user perspective.
-The recommendation is to implement a raw interface to the JSRMI protocol and -have a generic dynamic proxy implementation on top of that. This way the API -support can easily be extended simply by implementing new interfaces for the -Javascript counterparts and generate dynamic proxies on the fly as needed.
-This is currently not possible.
- - \ No newline at end of file -- cgit v1.2.3