Client side development 2 - RiWAs

Client-side development 2 – RiWAs

RIAs Vs RiWAs

§  RiWAs can be explained in another perspective as RiWAs are the systems, which  combine the  power  of the rich  GUIs  and  DC  TTs  of  RIAs  with  the  Web-based applications.

§  The scope of the RiWAs  is  wider  than traditional Web-based applications in DC aspect; and wider than standard RIAs in types of client-components and their integration  aspects.

§  Furthermore,  aligning  to  the  types  of Web-based applications based  on the size, RiWAs can also be grouped as standalone RiWAs and multi-tier RiWAs.

§  The need for the introduction of this new domain RiWA and  referring  to  it  in  this  research  is  to  address  wider technological development possibilities, which are not likely covered  generally  by  the  term  RIA  under  the  domain  of Web-based applications.

§  The RiWAs can be seen as a hybrid concept of  Web-based applications  and RIAs;  and RiWAs can  gain  benefits  from  the  non-browser-based  client-components, more than Web-based systems, as discussed in the following section.

§  The client-components of RiWAs are similar to the client-components  of  Web-based  applications.  Additionally, they should  incorporate DC  handing components,  thus the ability  of  DC  development  is  needed  for  the  client-components  development.

§  There  are  several  approaches  for  the  browser-based RiWAs, inherited  from RIAs.

§  The  first approach, which is the proprietary plugin based approach, uses the technologies such as Adobe (former Macromedia) Flash/Flex [13], JAVA Applets,  or  MS  Silverlight.

§  If  the  client-component  is  non-browser-based,  regular HTTP communication may not be required. Instead, all the communication  could  be  accomplished  using  DC.  For browser-based  client-components,  there  is an  approach  of developing  all  the  features  in  a  single  Web  page,  called single page  paradigm.

§  In  such applications, other  than the initial  request for  the  Web  page –  which  contains all  the client-components – for rest of the communication, only DC can be  used.

§  For other  standard RiWAs,  a combination of regular  HTTP  requests  –  via  HTML  hyperlinks,  JS redirections, or forms submission – and DC can be utilized, according  to  the  requirements  and  the  delivery  of  the features aligning to the system design.

Key features of RiWAs

§  An  in-depth  discussion  of  the  features  and characteristics  of  different  types  of  RiWAs  and  their development  TTs  is  intentionally  avoided  in  this  paper.

§  Instead, this section analyses the  RiWAs development TTs, classifies them, and presents taxonomies in the direction of structured understanding of their usage. We expect that these taxonomies  will  help  to  realize  the  functionalities  of  the components of the intended architectural style.

Technologies and Techniques used in RiWAs

§  Towards the  TTs independency  of an  architectural style for  RiWAs  –  which  is  the  main  focus  of  our  ongoing research – it is essential to have an adequate understanding of the  Towards the  TTs independency  of an  architectural style for  RiWAs  –  which  is  the  main  focus  of  our  ongoing research – it is essential to have an adequate understanding of the  development  TTs  of  the  RiWAs  and  their  proper utilization.

§  This knowledge will  also help in demonstrating how  the  intended  style  can  be  adopted  in  RiWAs development. 

§  An  in-depth  discussion  of  the  features  and characteristics  of  different  types  of  RiWAs  and  their development  TTs  is  intentionally  avoided  in  this  paper. Instead, this section analyses the  RiWAs development TTs, classifies them, and presents taxonomies in the direction of structured understanding of their usage.

§  We expect that these taxonomies  will  help  to  realize  the  functionalities  of  the components of the intended architectural style. As Meliá et al.  [11] say that the real challenge in SE is selecting  the  right  and  suitable  TTs  for  the  project  from existing  alternatives,  and  creating  the  optimal  solution  to satisfy the user requirements.

§  Adequate understanding of the TTs  used  in  the  development  of  RiWAs  may  provide sufficient assistance in the effort of designing the proposed architectural style for RiWAs to be TTs independent.

§  This knowledge  will  also  assist  in  the  decision  making  of selecting  proper TTs for  the  development of  RiWAs,  and hassle-less adoption of them,  via the conceptual realization provided by the taxonomies.

TTs for the Client-Components of RiWAs

§  The client-components of RiWAs are similar to the client-components  of  Web-based  applications  [2].  Additionally, they should  incorporate DC  handing components,  thus the ability  of  DC  development  is  needed  for  the  client-components  development  TTs.

 

§  It  should  be  noted  that  when  the  client-side development of  RiWAs is considered, it  includes not only the  application  component  development  but  also  the Views/GUI development.

TTs for the Connector Elements of RiWAs

§  Connector development TTs  can be  seen as  the core of RiWAs  development TTs. 

§  In addition to  the connector of Web-based  applications,  the  connectors  in  RiWAs incorporate  DC,  where  both  the  client  and  server  should contain  components  for  handling  DC.

 

§  For  the communication  in  RiWAs,  union  of  the  communication development TTs of traditional Web-based systems and the DC development TTs is accepted.

Delta-Connection

§  The  rich  communication  model  of  the  RIAs  is  called Delta Communication (DC), with three main characteristics: capability  of processing  in background,  which  helps in partial  page  rendering, faster  communication  than  the communication used in web-based application, which leads to  improving the  responsiveness  by eliminating  the  work-wait pattern, and support for development of the features in both synchronous and asynchronous processing.

§  DC can be seen as the power of the RIAs and it is defined as ―the rich communication model used by the rich features of the RIAs, for client-component(s) to communicate with the server-component(s), to exchange only the needful dataset – for  a  particular  feature  executed  at  the  time  –  which  is smaller,  compared  to  the  size  of  the  request/response  of traditional  communication.  Since  the  size  of  the  dataset communicated  is  smaller,  the  communication  completes faster, eliminating the work-wait pattern.

§  The processing of the  response  is  done  by  the  client-components  in  the background, therefore the page refreshes are eliminated and replaced by partial page rendering to update the content of the GUI with the results of the response. The user experience can be determined by  the implementation of  the feature, in either  blocking  (synchronous)  or  non-blocking (asynchronous) modes.

Evolution of the XHR and AJAX

§  AJAX stands for Asynchronous JavaScript And XML. AJAX is not a new technology but it is a technique. It is a term that is firstly penned by James Garrett in 2005.

§  Basically, It is a way of using many existing technologies like HTML, CSS, JavaScript, XML, Document Object Model, and main important part is XMLHttpRequest (XHR) object.

§  When all these technologies work together with AJAX technique, User Interface updates itself without reloading the whole web page.

§  Basically, AJAX will communicate with the server, get data from the server, update UI based on that data without reloading the whole web page.

History of AJAX

§  AJAX stands for Asynchronous JavaScript And XML. AJAX is not a new technology, but it is a technique. It is a term that is firstly penned by James Garrett in 2005.

§  Basically, It is a way of using many existing technologies like HTML, CSS, JavaScript, XML, Document Object Model, and main important part is XMLHttpRequest (XHR) object.

§  When all these technologies work together with AJAX technique, User Interface updates itself without reloading the whole web page. Basically, AJAX will communicate with the server, get data from the server, update UI based on that data without reloading the whole web page.

DC-Engine in RiWAs

The rich communication model of the RIAs is called Delta Communication (DC), with three main characteristics:  capability of processing in background, which helps in partial page rendering,

§  faster communication than the communication used in web-based application, which leads to improving the responsiveness by eliminating the work wait pattern

§  support for development of the features in both synchronous and asynchronous processing.

§  DC can be seen as the power of the RIAs and it is defined as ―the rich communication model used by the rich features of the RIAs, for client-component(s) to communicate with the server-component(s), to exchange only the needful dataset – for a particular feature executed at the time – which is smaller, compared to the size of the request/response of traditional communication. Since the size of the dataset communicated is smaller, the communication completes faster, eliminating the work-wait pattern. The processing of the response is done by the client-components in the background, therefore the page refreshes are eliminated and replaced by partial page rendering to update the content of the GUI with the results of the response. The user experience can be determined by the implementation of the feature, in either blocking (synchronous) or non-blocking (asynchronous) modes‖. The basic model of the DC is called Simple Pull Delta Communication (SPDC) model, which is defined as ―the basic abstract Delta-Communication technique, based on the data-pull mode. It describes the simplest form of datapull Delta-Communication, based on the request-response model; and this technique is technology independent. The JavaScript (JS) implementation of the SPDC – which is called the ―JavaScript-based Simple Pull DeltaCommunication‖ (JS-SPDC) – is the simplest implementation of the SPDC, which is commonly known as Asynchronous Javascript And XML (AJAX).

JQUERY FOR AJAX-BASED DC

Different browsers implement the Ajax differently that means if you're adopting the typical JavaScript way to implement the Ajax you have to write the different code for different browsers to ensure that Ajax would work cross-browser.

But, fortunately jQuery simplifies the process of implementing Ajax by taking care of those browser differences. It offers simple methods such as load(), $.get(), $.post(), etc. to implement the Ajax that works seamlessly across all the browsers.

·        jQuery load() Method

The jQuery load() method loads data from the server and place the returned HTML into the selected element. This method provides a simple way to load data asynchronous from a web server. The basic syntax of this method can be given with:

The parameters of the load() method has the following meaning:

·         The required URL parameter specifies the URL of the file you want to load.

·         The optional data parameter specifies a set of query string (i.e. key/value pairs) that is sent to the web server along with the request.

·         The optional complete parameter is basically a callback function that is executed when the request completes. The callback is fired once for each selected element.

Further, the callback function can have three different parameters:

·         responseTxt — Contains the resulting content if the request succeeds.

·         statusTxt — Contains the status of the request such as success or error.

·         jqXHR — Contains the XMLHttpRequest object.

·        jQuery $.get() and $.post() Methods

The jQuery's $.get() and $.post() methods provide simple tools to send and retrieve data asynchronously from a web server. Both the methods are pretty much identical, apart from one major difference — the $.get() makes Ajax requests using the HTTP GET method, whereas the $.post()makes Ajax requests using the HTTP POST method.

The basic syntax of these methods can be given with:

The parameters in the above syntax have the following meaning:

·         The required URL parameter specifies the URL to which the request is sent.

·         The optional data parameter specifies a set of query string (i.e. key/value pairs) that is sent to the web server along with the request.

·         The optional success parameter is basically a callback function that is executed if the request succeeds. It is typically used to retrieve the returned data.

·        jQuery noConflict() Method

The jQuery.noConflict() method return the control of the $ identifier back to other libraries. The jQuery code in the following example (line no-10) will put the jQuery into no-conflict mode immediately after it is loaded onto the page and assign a new variable name $j to replace the $alias in order to avoid conflicts with the prototype framework.