 AJAX technology  Rich User Experience  Characteristics  Real live examples  JavaScript and AJAX  Web application workflow model – synchronous vs asynchronous  XMLHttpRequest object  Response data processing

 Compare desktop application against web page  The desktop app responses interactively and quickly  Gives feedback instantly (doesn’t reload every time)  More natural  The web site reloads every time to provide the user with response

 Workflow is "Click, wait, load"  All events that need feedback need the page to reload from server  Synchronous request/response model  Page-driven  Logic is determined by server  Very hard to become flexible

 Interrupts user activity while loading  Looses context of operation during loading (e.g..: scrolled position)  No instant feedback  Constrained by HTML

 Rich Internet Applications can be developed as:  Applet  Flash  Java WebStart  DHTML  DHTML with hidden IFrame  AJAX

 DHTML with asynchronous communication capability via XMLHttpRequest  Most viable RIA technology  All browsers support it, although there are some incompatibilities  no plug-ins or additional code required  Many components developed, using it

 Applications that take advantage of AJAX:  Google maps  Google Suggests  NetFlix  Gmail  Yahoo Maps  Many more emerging

 The user can drag the map with the mouse, instead of clicking (compare with )  The action that triggers loading of images is moving the map around  The map data is downloaded asynchronously via AJAX  Other parts of the page remain the same  No loss of operation context

Classic web application (synchronous) AJAX web application (asynchronous) User operation is interrupted while fetching data User operation is interrupted while fetching data User operation is NOT interrupted while fetching data User operation is NOT interrupted while fetching data

 JavaScript object  Supported by Mozilla, Opera, Safari,  Supported by IE as ActiveX control  Communicates with server via GET/POST requests  Performs in the background asynchronous communication with the server  Does not interrupt user workflow

 Server remains the same  Receives standard GET/POST request  Has few constrains:  Requests are more frequent  Response content type can be:  text/xml  text/plain  text/json  text/javascript

 open ("HTTP Method", "URL", "synchronous or asynchronous);  Assigns HTTP method, request URL and mode  send (content);  Sends the request  abort();  Terminates request  getAllResponseHeaders ();  Returns all HTTP headers of the response (name + value) as string

 getResponseHeader ("header");  Returns value of the specified header  setRequestHeader ("name", "value");  Sets request header before sending the request

 onreadystatechange  JavaScript event handler function, that fires at each state change  readyState  Current status of the request  0 – uninitialized  1 – loading  2 – loaded  3 – interactive (some data was received  4 – complete  Status  The HTTP status returned from server

 responseText  String, containing data, returned from server  responseXML  XML document tree, containing the data from the server  statusText  Status text, returned from server

 Server side - AJAX applications use the same server-side schemes  Subject to same security issues as regular web application  Cross-site scripting  Injection flaw

 Client side  The JavaScript code is visible to the user  Can be used for inferring weaknesses of server security, unless obfuscation or compression is used  The code is downloaded from server and executed at client side  Can compromise client by mal-intended code  JavaScript code is constrained by the sandbox model

 When user is using Ajax application the actions taken do not update the browser history  When pressing back or refresh buttons the state is lost  Page fragment identifier is the part of the URL after the # sign  We can set the page URL changing only the page fragment identifier  Doesn’t reload the page  Affects history

 Although the page-fragment solution does work for bookmarks it is still no good for back/forward buttons  We can use hidden iframes  When there is frame in the page the back/forward buttons control them  The frame content can control the overall page  Mixing the iframe and the page fragment approaches may lead to problems!