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:
  • dojo.data is an API specification like JDBC or ODBC. A dojo.data driver implements this specification and responds to requests from your data-enabled widgets or JavaScript code. 
  • The dojo.io.script 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 dojo.data doese. They also require a server-side proxy to call services outside your domain. But dojo.xhr* works without writing a compatible dojo.data driver, and they can use data in any format. The are best for off-site services that don't support JSONP.
Generally, dojo.data is the most sophisticated of the three. It's drivers are bilt on the dojo.io.script 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(){
dojo.xhrGet({
url: "demo/id1" ,
handle: function(response){
if (response instanceof Error) {
//failed...
alert("failed: " + response.message);
}
else {
//success...
alert('succeeded: "' + response + '"' );
}
}
});
}

or

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...
dojo.xhrGet({
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(){
 dojo.xhrGet({
 url: "demo/id2" ,
 handleAs: "json" ,
 handle: handler3
 });
 }




Comments

Popular posts from this blog

Quicksort implementation by using Java

 source: http://www.algolist.net/Algorithms/Sorting/Quicksort. The divide-and-conquer strategy is used in quicksort. Below the recursion step is described: 1st: Choose a pivot value. We take the value of the middle element as pivot value, but it can be any value(e.g. some people would like to pick the first element and do the exchange in the end) 2nd: Partition. Rearrange elements in such a way, that all elements which are lesser than the pivot go to the left part of the array and all elements greater than the pivot, go to the right part of the array. Values equal to the pivot can stay in any part of the array. Apply quicksort algorithm recursively to the left and the right parts - the previous pivot element excluded! Partition algorithm in detail: There are two indices i and j and at the very beginning of the partition algorithm i points to the first element in the array and j points to the last one. Then algorithm moves i forward, until an element with value greater or equal

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        

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"/>