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

Spring - Operations with jdbcTemplate

This class manages all the database communication and exception handling using a java.sql.Connection that is obtained from the provided DataSource. JdbcTemplate is a stateless and threadsafe class and you can safely instantiate a single instance to be used for each DAO.

Use of Callback Methods
JdbcTemplate is based on a template style of programming common to many other parts of Spring. Some method calls are handled entirely by the JdbcTemplate, while others require the calling class to provide callback methods that contain the implementation for parts of the JDBC workflow. This is another form of Inversion of Control. Your application code hands over the responsibility of managing the database access to the template class. The template class in turn calls back to your application code when it needs some detail processing filled in. These callback methods are allowed to throw a java.sql.SQLException, since the framework will be able to catch this exception and use its built-in excepti…