Skip to main content

Learning Dojo: Dojo Remote Scripting

Native Remote Scripting
There are three well-known methods to implement native remote scripting:

  • Using an XMLHttpRequest(XHR) object
  • Dynamically loading an iframe element
  • Dynamically loading a script element

XHR (XmlHttpRequest)

XHR is easy to use naively but hard to use correctly. Some of its many weirdisms include the following:

  • An unfamiliar syntax. Many developers simply copied and pasted XHR code snippets but had no idea what the code was doing. That makes debugging... ehhhh, not so fun.
  • Poor handling of content types. Though XHR is supposed to speak XML fluently, you colud hand back valid XML from the server and still get a head-scratching " Not valid XML" message from XHR.
  • No help in creating the parameter string. You had to do all the URL encoding yourself, or perhaps you didn't do it at all.. and the first & in a textbox broke your application.
Dojo's remote scripting facilities enable a client-side script to communicate with a server without a page reload. There are threee Dojo techniques for service connections:
  • is an API specification like JDBC or ODBC. A driver implements this specification and responds to requests from your data-enabled widgets or JavaScript code. 
  • The method access with Padding(JSONP) services in other domains. XHM must follow the same origin rule you can call only those services housed on the same server as the outer page. 
  • The dojo.xhrGet, dojo.xhrPost, dojo.rawXhrPost, dojo.xhrPut, dojo.rawXhrPut, dojo.xhrDelete, and dojo.xhr methods are the lowest-level remote scripting services. These methods, collectively called dojo.xhr*, don't provide the common API layer and translation services that doese. They also require a server-side proxy to call services outside your domain. But dojo.xhr* works without writing a compatible driver, and they can use data in any format. The are best for off-site services that don't support JSONP.
Generally, is the most sophisticated of the three. It's drivers are bilt on the and dojo.xhr* methods

For example:
Caling dojo.xhr*

function example()
dojo.xhrGet( {
    url: "demo/id1",
    load: function(response){ alert(response"},
    error: function(error) { alert(error.message); }

load: the function to call on succcessful completion of the request.
And we relied upon default values for these items:

  • handleAs(a string): how to prepocess the response; defaults to handle as "text", which implies no preprocessing is executed on the response.
  • sync ( a boolean): Sends the XHR synchronously or not: defaults to send asynchronously
  • preventCache (a boolean): prevents cached resources from being returned : defaults to false

It is also possible to specify one function to handle both success and failure condition.

function example2(){
url: "demo/id1" ,
handle: function(response){
if (response instanceof Error) {
alert("failed: " + response.message);
else {
alert('succeeded: "' + response + '"' );


function example4(){
 //get some variables that we'll use in the handler function...
 var targetNode= dojo.byId("result" );

 //make a handler closed on the variables we made...
 function handler2(response){
 var error= response instanceof Error;
 var responseText= error ? response.message : response;
 targetNode.innerHTML= responseText.replace(/</g, "&lt;" );
 dojo.toggleClass(targetNode, "error" , error);

//note: NOT dumping anything...
dojo.byId("objects" ).innerHTML= "" ;

//make the XHR call...
url: "demo/id1" ,
handle: handler2

Or using JSON:

function handler3(response, ioArgs){
 var error= response instanceof Error;
 var responseText= error ? response.message : ioArgs.xhr.responseText;
 var resultNode= dojo.byId("result" );
 resultNode.innerHTML= responseText.replace(/</g, "&lt;" );
 dojo.toggleClass(resultNode, "error" , error);
 dojo.byId("objects" ).innerHTML=  dumpObject({response: response});

 function example(){
 url: "demo/id2" ,
 handleAs: "json" ,
 handle: handler3


Popular posts from this blog

Stretch a row if data overflows in jasper reports

It is very common that some columns of the report need to stretch to show all the content in that column. But  if you just specify the property " stretch with overflow' to that column(we called text field in jasper report world) , it will just stretch that column and won't change other columns, so the row could be ridiculous. Haven't find the solution from internet yet. So I just review the properties in iReport one by one and find two useful properties(the bold highlighted in example below) which resolve the problems.   example:
<band height="20" splitType="Stretch"> <textField isStretchWithOverflow="true" pattern="" isBlankWhenNull="true"> <reportElement stretchType="RelativeToTallestObject" mode="Opaque" x="192" y="0" width="183" height="20"/> <box leftPadding="2"> <pen lineWidth="0.25"/> …

JasperReports - Configuration Reference

Live - solving the jasper report out of memory and high cpu usage problems

I still can not find the solution. So I summary all the things and tell my boss about it. If any one knows the solution, please let me know.

Symptom: 1.The JVM became Out of memory when creating big consumption report 2.Those JRTemplateElement-instances is still there occupied even if I logged out the system
Reason:         1. There is a large number of JRTemplateElement-instances cached in the memory 2.The clearobjects() method in ReportThread class has not been triggered when logging out
Action I tried:      About the Virtualizer: 1.Replacing the JRSwapFileVirtualizer with JRFileVirtualizer 2.Not use any FileVirtualizer for cache the report in the hard disk Result: The japserreport still creating the a large number of JRTemplateElement-instances in the memory     About the work around below,      I tried: item 3(in below work around list) – result: it helps to reduce  the size of the JRTemplateElement Object                Item 4,5 – result : it helps a lot to reduce the number of  JRTemplateE…