Source code for /src/remotescript2.htm.txt
//======================================================================//
// Author: Mark Qian <markqian@hotmail.com> //
// WWW: http://www.coolshare.com //
// Copyright (c) 2006, Mark Qian //
// //
// You must contact Mark Qian to get a permission of use //
// in case you want to make any use of the codes except viewing it //
// on Mark's site. //
//======================================================================//
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<META http-equiv="Page-Enter" CONTENT="RevealTrans(Duration=4,Transition=23)">
<head>
<title>Remote Scripting</title>
</head>
<script src="/html/js/expand.js"></script>
<body background="../images/rulebk.jpg">
<table><tr><td><table width=70><tr><td></td></tr></table></td><td><table><tr><td>
<center> <h2>It isn't called AJAX but Remote Scripting</h2>
(By Mark Qian on 7/14/2006)
<br>
<br>
<br>
<img src="../images/cool_003.gif" border=0><B>Related article by Mark Qian: <a href="http://www.newframework.com" target=_blank>"What is wrong with those most popular web application frameworks?"</a></b>
<br><br>at <a href="http://www.RemoteScriptGuru.com" target=_blank>http://www.NewFramework.com</a>
<br>
<br>
</center>
<br>
(underconstruction...Latest update is indicated by <a href="#_new"></a> sign)
<pre><font size=4>
<h3>PREFACE</h3>
It seems that the word "<b>AJAX</b>" has been flooded everywhere these days when people
are talking about web development. People use "AJAX" to label a much bigger
territory, <b>Remote Scripting</b>. If you think AJAX is <b>as "simple" as</b>
- create a XMLHttpRequest Object
- make a call with callback handler
- handle server response in the handler
<b>you are wrong</b>. AJAX, no, <b>Remote Scripting</b>, means not only being able to make requests to server and update your
pages partially without reloading the entire pages but also introduces a totally different manner of communication
to the server. The intention is "minimizing loading entire page" to save communication bandwidth, reduce server load,
and optimize visual effect. On the other hand, <b>Remote Scripting</b> breaks some traditional "rules" that browser
originally introduced and people have got along with such as going Backward and Forward in web surfing history,
client-state preservation.
<b>The goal</b> of this paper is starting at what AJAX has and what are shorted in "AJAX" to <b>bring up most major
issues and their solutions/approaches on Remote Scripting</b>. For each issue, illustrate them at two levels:
<b>1)</b>. A variety of solutions (either by Mark Qian or others) on <b>remote scripting</b> will be listed.
<b>2)</b>. For each solution, a variety of live implementation will be shown(either by Mark Qian or others).
I tried to make all the description as "alife" as possible with real codes running. You may want to pay more
attantion to <a href="#_new"></a> signs while you are reading to see things running outside "paper".
<h3>A. What does AJAX have?</h3>
AJAX, Asynchronous JavaScript and XML, is just a feature, relatively "newly"
being available in browsers which implemented it differently. So let's see
what this browser feature offers.
<A NAME="_comm"></A>
<b>a.Communicate with server Asynchronously</b>
<ul><ul><li>Forces</li>(<a id="Aa1" href="javascript:void(0)" onclick="divExpand(this);return false;"onMouseover="showtip()" onMouseout="hidetip()" style="text-decoration:none"></a>):
<div id="d_Aa1" style="display:none;background-color:#CCFFFF;border-style: inset;width:1200"><pre>
The major technology AJAX relies on, in term of communication, is XMLHttpRequest (XHR). XMLHttpRequest
is mostly used to "silently" update a part or entire screen in a web application without reloading
web entire pages. I will illistrate a variety of solutions on "Communicate with server Asynchronously".
For each solution, I will list different implementations.
I will also show how to use a single "wrapper", <b>Mark's Communicator</b>, to wrap a variety of
implementation details through all the solutions.
</pre></div>
<li>Solutions</li>(<a id="Aa2" href="javascript:void(0)" onclick="divExpand(this);return false;"onMouseover="showtip()" onMouseout="hidetip()" style="text-decoration:none"></a>):
<div id="d_Aa2" style="display:none;background-color:#CCFFFF;border-style: inset;width:1200"><pre>
<ul><ul><li><b>AJAX</b></li>
XMLHttpRequest is used in this approach but there may be many low level details such as
XMLHttpRequest pooling, progress indication and so on. One way to make life easier is to
wrap them in a js object and even make transport (in term of DOJO) transparent to users.
<A NAME="_new"></A>
<b>Here are a variety of implementation</b>:
<b>1</b>. Mark's implementation using <b>Mark's Communicator</b> for "an autocomplete component".
In this example, XMLHttpRequest is wrapped as a "Communicator" so that the details
of communication management such as pooling, progress indicator is transparent to
programmers.
<b><a href="http://RemoteScriptGuru.com/RemoteScriptGuru/remote_script.issue_1_comm.ajax1.do" target=_blank>Demo</a></b>, <b><a href="http://RemoteScriptGuru.com/RemoteScriptGuru/remote_script.issue_1_comm.ajax1.do#_src" target=_blank>Codes</a></b> and Design.
<b>2</b>. Mark's implementation using <b>Mark's Communicator</b> to build a on-demand js tree.
In this example, XMLHttpRequest is wrapped as a "Communicator" so that the details
of communication management such as pooling, progress indicator is transparent to
programmers.
<b><a href="http://remotescriptguru.com/RemoteScriptGuru/jsp/javascriptlab/ajax/on_demand_tree/od_tree_top.jsp?a=AJAX" target=_blank>Demo</a></b>, <b><a href="http://remotescriptguru.com/RemoteScriptGuru/jsp/javascriptlab/ajax/on_demand_tree/od_tree_top.jsp?a=AJAX" target=_blank>Codes</a></b> and Design.
<b>3</b>. Mark's implementation using DOJO. <b>Demo</b> and <b>Codes</b>.
<li><b>Dynamic hidden iFrame</b></li>
Dynamic hidden iFrame is used in this approach but unlike AJAX, we need to save the reference
to handlers globally so that we can retreave them when server response return. One way to achieve
this is to wrap the implmentation details in a js object, say Communicator and have a "Mananger"
sites globally managing Communicators. I will show a variety of ways and how to use them below.
<b>Here are a variety of implementation</b>:
<b>1</b>. Mark's implementation using <b>Mark's Communicator</b> for "an autocomplete component".
In this example, the iframe will be create dynamically and wrapped as a "Communicator"
so that the details of communication management such as pooling, progress indicator is transparent to
programmers.
<b><a href="http://RemoteScriptGuru.com/RemoteScriptGuru/remote_script.issue_1_comm.iframe1.do" target=_blank>Demo</a></b>, <b><a href="http://RemoteScriptGuru.com/RemoteScriptGuru/remote_script.issue_1_comm.iframe1.do#_src" target=_blank>Codes</a></b> and Design.
<b>2</b>. Mark's implementation using <b>Mark's Communicator</b> to build a on-demand js tree.
In this example, XMLHttpRequest is wrapped as a "Communicator" so that the details
of communication management such as pooling, progress indicator is transparent to
programmers.
<b><a href="http://remotescriptguru.com/RemoteScriptGuru/jsp/javascriptlab/ajax/on_demand_tree/od_tree_top.jsp?a=Iframe" target=_blank>Demo</a></b>, <b><a href="http://remotescriptguru.com/RemoteScriptGuru/jsp/javascriptlab/ajax/on_demand_tree/od_tree_top.jsp?a=Iframe" target=_blank>Codes</a></b> and Design.
<b>3</b>. Mark's implementation using <b>DOJO. Demo</b> and <b>Codes</b>.
<li><b>Dynamic Scripting (cross-domain)</b></li>
Dynamic Scripting is used in this approach. Similar to iframes, we need to save the reference
to handlers globally so that we can retreave them when server response return. One way to achieve
this is to wrap the implmentation details in a js object, say Communicator and have a "Mananger"
sites globally managing Communicators. I will show a variety of ways and how to use them below.
<b>Here are a variety of implementation</b>:
<b>1</b>. Mark's implementation using <b>Mark's Communicator</b> for "an autocomplete component".
In this example, the script section for communication will be create dynamically and wrapped as a "Communicator"
so that the details of communication management such as pooling, progress indicator is transparent to
programmers.
<b><a href="http://RemoteScriptGuru.com/RemoteScriptGuru/remote_script.issue_1_comm.ds1.do" target=_blank>Demo</a></b>, <b><a href="http://RemoteScriptGuru.com/RemoteScriptGuru/remote_script.issue_1_comm.ds1.do#_src" target=_blank>Codes</a></b> and Design.
<b>2</b>. Mark's implementation using <b>Mark's Communicator</b> to build a on-demand js tree.
In this example, XMLHttpRequest is wrapped as a "Communicator" so that the details
of communication management such as pooling, progress indicator is transparent to
programmers.
<b><a href="http://remotescriptguru.com/RemoteScriptGuru/jsp/javascriptlab/ajax/on_demand_tree/od_tree_top.jsp?a=DS" target=_blank>Demo</a></b>, <b><a href="http://remotescriptguru.com/RemoteScriptGuru/jsp/javascriptlab/ajax/on_demand_tree/od_tree_top.jsp?a=DS" target=_blank>Codes</a></b> and Design.
<b>3</b>. More approaches will be added here ...
<li><b>Hidden Frame</b></li>
The reason I am show this "old" way here is that it is the most compatible way
when something wrong with iframe such as it is too costful (in term of memory usage)
using iframe some broswers. You can turn off iframe, XMLHttpRequest, Cookies, but you
can not turn off static frames unless frames are not supported.
In this example, hidden frame is wrapped as a "Communicator" so that the details
of communication management such as progress indicator is transparent to
programmers.
<b>Here are a variety of implementation</b>:
<b>1</b>. Mark's implementation using <b>Mark's Communicator</b> for "an autocomplete component".
<b><a href="http://RemoteScriptGuru.com/RemoteScriptGuru/jsp/remote_script/issue_1_comm/frame/frame1.jsp" target=_blank>Demo</a></b>, <b><a href="http://RemoteScriptGuru.com/RemoteScriptGuru/jsp/remote_script/issue_1_comm/frame/frame1.jsp#_src" target=_blank>Codes</a></b> and Design.
<b>2</b>. Mark's implementation using <b>Mark's Communicator</b> to build a on-demand js tree.
In this example, XMLHttpRequest is wrapped as a "Communicator" so that the details
of communication management such as pooling, progress indicator is transparent to
programmers.
<b><a href="http://remotescriptguru.com/RemoteScriptGuru/jsp/javascriptlab/ajax/on_demand_tree/od_tree_top.jsp?a=Frame" target=_blank>Demo</a></b>, <b><a href="http://remotescriptguru.com/RemoteScriptGuru/jsp/javascriptlab/ajax/on_demand_tree/od_tree_top.jsp?a=Frame" target=_blank>Codes</a></b> and Design.
<b>3</b>. More approaches will be added here ...</li>
<li><b>Image/Cookies</b></li>
The trick is using src of image to send the request and use cookies to send
and retreave respond. The limitation of this approach is that it relies on
browser cookies.
Another usage of image trick is that in case you don't need the server respond (that is, you
only want to send server a message to update some state at the server side but no need to update any state
at the client side), you can use the image src to send your request.
<b>Here are a variety of implementation</b>:
Brent's <b>RSLite</b> is a typical implementation of this approach:
"RSLite is an extremely lightweight implementation of remote scripting which uses cookies.
It is very widely browser-compatible (Opera!) but limited to single calls and small
amounts of data... " by <a href="http://www.ashleyit.com/blogs/brentashley/" target=_blank>Brent Ashley</a>
<b>1</b>. Brent Ashley's implementation of "Get Server Var" using <b>RSLite</b>.
<b><a href="http://www.ashleyit.com/rs/rslite/" target=_blank>Demo</a></b> and <b><a href="http://www.ashleyit.com/rs/rslite/rslite.js.txt" target=_blank>Codes</a></b>.
<b>2</b>. Mark's implementation using <b>Mark's Communicator</b> to build a on-demand js tree.
In this example, XMLHttpRequest is wrapped as a "Communicator" so that the details
of communication management such as pooling, progress indicator is transparent to
programmers.
<b><a href="http://remotescriptguru.com/RemoteScriptGuru/jsp/javascriptlab/ajax/on_demand_tree/od_tree_top.jsp?a=Cookie" target=_blank>Demo</a></b>, <b><a href="http://remotescriptguru.com/RemoteScriptGuru/jsp/javascriptlab/ajax/on_demand_tree/od_tree_top.jsp?a=Cookie" target=_blank>Codes</a></b> and Design.
<b>3</b>. Mark's implementation of "an autocomplete component" using <b>Mark's Communicator</b> with <b>RSLite</b>.
See how can I wrap RSLite within my Communicator to make it transparent to programmers.
<b><a href="http://RemoteScriptGuru.com/RemoteScriptGuru/remote_script.issue_1_comm.cookie1.do" target=_blank>Demo</a></b> and <b><a href="http://RemoteScriptGuru.com/RemoteScriptGuru/remote_script.issue_1_comm.cookie1.do" target=_blank>Codes</a></b>.
<b>4</b>. More approaches will be added here ...</li>
</ul></ul>
</pre></div></ul></ul>
<b>b. More "AJAX has" features will be added here ...</b>
</ul>
<h3>B. What doesn't AJAX have?</h3>
AJAX is actually a "subset" of "Remote scripting". Personally, I think it is the worst approach
(Why? See my explanation in "<a href="http://www.coolshare.com/newframework/pages/what_is_wrong.htm#_problem3">What is wrong with those most popular web application frameworks?</a>")
amoung most of approches in "Remote scripting" territory. So it is why I use it as the starting
point to illustrate a variety of issues we need to face when remote scripting.
Let's take a look at the issues.
<b>a. AJAX can't be used cross domain</b>
<ul><ul><li>The Problem</li>(<a id="Ba1" href="javascript:void(0)" onclick="divExpand(this);return false;" onMouseover="showtip()" onMouseout="hidetip()" style="text-decoration:none"></a>):
<div id="d_Ba1" style="display:none;background-color:#CCFFFF;border-style: inset;width:1200"><pre>
XmlHttpRequest objects are limited by "the same origin" security policy of browsers.
Under the policy, objects and pages can not access data from different server. Actually,
this problem is not only AJAX's. It exists, "by default", on most remote scripting
approaches.
<A NAME="_cross_domain"></A>
There are two demos for this policy:
1). Client side communication. See the <b><a href="http://www.coolshare.com/remotescriptguru/html/cross_domain/same_origin/cross_domain_test_A.htm" target=_blank>Demo</a></b> showing the problem.
2). Client/Server communication. See the <b><a href="http://www.coolshare.com/remotescriptguru/html/cross_domain/same_origin/cross_domain_test_A2.htm" target=_blank>Demo</a></b> showing the problem.
To workaround, people have been having a variety of approaches/solutions.
</pre></div>
<li>Solutions</li>(<a id="Ba2" href="javascript:void(0)" onclick="divExpand(this);return false;" onMouseover="showtip()" onMouseout="hidetip()" style="text-decoration:none"></a>):
<div id="d_Ba2" style="display:none;background-color:#CCFFFF;border-style: inset;width:1200"><pre>
<ul><ul><ul>
<li><b>Dynamic scripting</b></li>
One approach is to make use of an exception of the "same origin" rule. The rule thinks
"Any script directly included on a page, is assumed to come from the same domain as the page
it is included in". This approach is more feasible since there is not suffix constrain (see
the "Changing document.domain" below)
<b>1</b>. Mark's implementation allowing you <b>contain content loaded from any
domain in a single page</b>.
See the <b><a href="http://www.coolshare.com/remotescriptguru/html/cross_domain/dynamic_script/cross_domain_dynamic_script.htm" target=_blank>Demo</a></b> in a non-frame page (<b>div</b> is used to divide areas for
content loaded from different domains) here.
See the <b><a href="http://www.coolshare.com/remotescriptguru/html/cross_domain/dynamic_script/cross_domain_dynamic_script2.htm" target=_blank>Demo</a></b> in a page with iframe (<b>iframe</b> is used to divide areas for
content loaded from different domains) here.
<b>2</b>. Articles about Dynamic scripting.
- <a href="http://www.acheron.org/darryl/?p=28" target=_blank>"AJAX with dynamic SCRIPT tags - revised"</a> by Darryl Lyons' Blog
- <a href="http://www.ariadne-cms.org/news/00009/" target=_blank>"Cross-domain Partial Page Updates with JavaScript"</a> by Auke van Slooten
<li><b>Changing document.domain</b></li>
Another one is trying to make browsers think two frames are loaded from the
"same origin".
JavaScript provides the document.domain property allowing cooperating sites to
remove this restriction for their particular Web sites, i.e., pages which
specifically set the document.domain property can override (to an extent)
the Same-Origin policy to allow scripts to read and write values across
frames as if both pages did come from the same domain.
Limitation:
- You only set document.domain to a suffix of the original domain the page is loaded from.
- Once document.domain is used in one page it needs to be set in all other pages
- Some XmlHttpRequest in some browser such as Mozilla doesn’t acknowledge the
document.domain setting. So there is no way to communicate between different servers
directly through it.
Abe Fettig introduced a his attempts on approach.
<a href="http://fettig.net/playground/ajax-subdomain/test5.html" target=_blank><b>Demo</b></a> and <a href="http://fettig.net/weblog/2005/11/28/how-to-make-xmlhttprequest-connections-to-another-server-in-your-domain/" target=_blank><b>Codes</b></a>
<li><b>Proxy script in CPAINT</b></li>
<a href="http://cpaint.wiley14.com/" target=_blank><b>Codes</b></a>
<li><b>mod_rewrite (Available in Apache 1.2 and later)</b></li>
<a href="http://httpd.apache.org/docs/1.3/mod/mod_rewrite.html" target=_blank><b>API</b></a> at Apache and <a href="http://premshree.livejournal.com/66129.html" target=_blank><b>Sample</b></a> from premshree.livejournal.com
<li><b> Dynamic Script Tag & JSON</b></li>
<a href="http://www.xml.com/pub/a/2005/12/21/json-dynamic-script-tag.html" target=_blank><b>Codes</b></a> from Jason Levitt.
<li><b>Server-side reverse proxying</b></li>
<li><b>Bypassing XmlHttpRequest entirely</b></li>
<li><b>More approaches to be added...</b></li>
</ul></ul></ul>
</pre></div></ul></ul>
<A NAME="_back"></A>
<b>b. AJAX has problems with the "back" buttons and bookmark of browsers</b>
<ul><ul><li>The Problem</li>(<a id="Bb1" href="javascript:void(0)" onclick="divExpand(this);return false;" onMouseover="showtip()" onMouseout="hidetip()" style="text-decoration:none"></a>):
<div id="d_Bb1" style="display:none;background-color:#CCFFFF;border-style: inset;width:1200"><pre>
In traditional web pages, what users see is what they can bookmark and go forward and backward.
That is, every request users make back to the server is recorded in the browser's history.
With AJAX, views in pages may be changed without reloading the pages and these changes are
never recorded in some browser's history. The problem is that users can neither bookmark some
"views" they want to come back next time nor going back to a "previous view" (the fact
is sometimes the browser is completely moved out of the current site since the "previous view"
of that site is never in the history).
<A NAME="_back1"></A>
Here is how to see this kind of behaviour:
1). navigate your browser to site say "<a href="http://www.microsoft.com" target=_blank>microsoft.com</a>"
2). now go to a page with AJAX/Remote scripting, say "maps.google.com" (by typing
"maps.google.com" into the browser's location field and hitting go).
3). find your favor place, say "Mountain view, CA", by <b>zooming and panning</b>
4). bookmark the current view by select Favorites|Add to Favorites (in IE)
5). find another place in the map, say "Sunnyvale, CA", by <b>zooming and panning</b>
6). now, click at your favor "Back" button trying to return to your favor place,
"Mountain view, CA", in Google Maps. Suprisely , you will find that
you move out of Google on to the enemy's side, Microsoft.com.
7). OK, you may think, well, I had bookmarked the place ("Mountain view, CA") in the map.
So you click at the bookmarked item in your favorite list but what you will see
is the initial loading of Google Map the map of USA instead of "Mountain view, CA"
To workaround, people have been having a variety of approaches/solutions.
</pre></div>
<li>Solutions</li>(<a id="Bb2" href="javascript:void(0)" onclick="divExpand(this);return false;" onMouseover="showtip()" onMouseout="hidetip()" style="text-decoration:none"></a>):
<div id="d_Bb2" style="display:none;background-color:#CCFFFF;border-style: inset;width:1200"><pre>
<ul><ul><ul>
<li><b>Record Ajax actions and add them into the browser history</b></li>
<b>1</b>. Mark's implementation using <a href="http://www.onjava.com/pub/a/onjava/2005/10/26/ajax-handling-bookmarks-and-back-button.html" target=_blank>RSH</a>.
The open source Really Simply History framework (RSH) is a typical approach of this kind.
<b>Demo</b> and <b>Codes</b>.
</ul></ul></ul>
</pre></div></ul></ul>
<A NAME="_back"></A>
<b>c. AJAX does not preserve client-side page states</b>
<ul><ul><li>The Problem</li>(<a id="Bc1" href="javascript:void(0)" onclick="divExpand(this);return false;" onMouseover="showtip()" onMouseout="hidetip()" style="text-decoration:none"></a>):
<div id="d_Bc1" style="display:none;background-color:#CCFFFF;border-style: inset;width:1200"><pre>
Note: this problem is not "AJAX only". It may exist in any page keeping states in
javascript namespace but AJAX application is more "intend to" do that.
One nature of browsers is preserving page states in DOM components (in form) in their history
so that you can easily bookmark pages and use "Back" and "Forward" buttons.
Say, before you complete your email editing in Hotmail.com, you like to copy and paste some
info from a different site like Google.com and then return the Hotmail.com using "Back" button
to complete your email edition. This is fine with a "traditional" pages like the "new mail"
page at hotmail.com.
But the way AJAX application works on many pages is "only load the page once". A lot of state
info is preserved in javascript memory. And they may have some initialization function to setup
the page only once since it assumes the page is only loaded once and any further communication
will be carried out "silently" by XMLHttpRequest object. The problem is when users click at
"Back" button to return to the provious page they lose the state since the javascript namespace
is "refreshed" (gone when you switch away from the site and reloaded when reenter the site) and
initialization codes are called to clean the value in DOM.
<A NAME="_state1"></A>
Here is how you can try this kind of behaviour:
1). <a href="http://maps.google.com" target=_blank>go "map.google.com"</a> (where AJAX/remote scripting is used)
2). find whatever place you want to go (<b>zooming and panning</b>), say, your lovely hometown "Mountain view, CA",
3). type the enemy's site, "microsoft.com", in to the address field of your browser and go
to "microsoft.com"
4). click at your favor "Back" button
5). Ooh ooh: you moved (the map is initialized to the original position): "Mountain view, CA" in gone in the
view of Google map.
To workaround, people have been having a variety of approaches/solutions.
</pre></div>
<li>Solutions</li>(<a id="Bc2" href="javascript:void(0)" onclick="divExpand(this);return false;" onMouseover="showtip()" onMouseout="hidetip()" style="text-decoration:none"></a>):
<div id="d_Bc2" style="display:none;background-color:#CCFFFF;border-style: inset;width:1200"><pre>
<ul><ul><ul>
<li><b>Similar to the approach above (making up browser history): write states into DOM so that browser will add them into history</b></li>
Let's try <a href="#_state1">the experiment above</a> again in a different way:
instead of finding your favor place by <b>zooming and panning</b>, use the "Search Maps" field.
1). <a href="http://maps.google.com" target=_blank>go "map.google.com"</a> (where AJAX/remote scripting is used)
2). find whatever place you want to go , say, your lovely hometown "Mountain view, CA",
by <b>typing "Mountain view, CA" into the location field and click at "Search Maps" button</b>.
3). type the enemy's site, "microsoft.com", in to the address field of your browser and go
to "microsoft.com"
4). click at your favor "Back" button
5). Yes, you come back to "Mountain view, CA" in the map
<b>Why</b> is the state preserved now? The reason is that the state (the location "Mountain view, CA")
is stored in one of the DOM component the location text field (in a form) while the states are kept in javascript
objects when you change states by panning and zooming. That is, states resulted by panning and zooming
are stored in javascript namespace instead of DOM in Google Maps so they never appear in the browser's history.
(Of course, this is the intention of Google Map: never bother the browser history with tiny operations like
panning and zooming).
So you can obviously understand why people come out with this approach: don't (just) keep your state in javascript
objects but (also) write them into hidden DOM components like iframes so that browser will remember them.
Being "Remembered" in browser's history, on the other hand, may not always be a good thing. That may be a drawback
of this approach when you want to preserve the states but don't want them to appear in history.
<b>1</b>. <a href="http://codinginparadise.org/weblog/2005/08/ajax-tutorial-saving-session-across.html" target=_blank>Brad Neuberg's approach</a> is a typical one of this kind.
He used iframe to record the state and recover it when reloading.
<b>Demo</b> and <b>Codes</b>.
<li><b>Keep state in cookies</b></li>
<b>1</b>.
<b>Demo</b> and <b>Codes</b>.
</ul></ul></ul>
</pre></div></ul></ul>
<b>d. AJAX is bypassing the core of browsers, the renderers</b>
<ul><ul><li>The Problem</li>(<a id="Bd1" href="javascript:void(0)" onclick="divExpand(this);return false;" onMouseover="showtip()" onMouseout="hidetip()" style="text-decoration:none"></a>):
<div id="d_Bd1" style="display:none;background-color:#CCFFFF;border-style: inset;width:1200"><pre>
It is in javascript's namespace (execution context of the callback handler function)
when server response as "plain text" or dom is received. I said "plaint text" because
even though you can include script in the return but it won't be executed automatically
since the browser renderer is not involved.
</pre></div>
<li>Solutions</li>(<a id="Bd2" href="javascript:void(0)" onclick="divExpand(this);return false;" onMouseover="showtip()" onMouseout="hidetip()" style="text-decoration:none"></a>):
<div id="d_Bd2" style="display:none;background-color:#CCFFFF;border-style: inset;width:1200"><pre>
<ul><ul><ul>
<li><b>AJAX</b></li>
You can parse the return "plaint text" to extract the script area (many people
place script in the header area) and eval it yourself. The problem with this
approach is that parsing and eval are not a fun job. You need to carefully escape
special characters. And it becomes more complication when the script is not simple such
as a lib and multiple closure functiions need to be invoked in certain sequence.
In that case, your code logic may need to be duplicated: one for normally loading
process by browser's renderers and the other for eval.
Here are <b>Demo</b> and <b>Codes</b>.
<li><b>Dynamic hidden iFrame</b></li>
This problem is not a problem to iframes since browser will render the return content
and the script will be executed within the hidden iframe. And no extra logic is needed
since you only use a single piece of code for both types of request.
Here are <b>Demo</b> and <b>Codes</b>.
<li><b>Hidden frame</b></li>
Similar to the iframe approach.
Here are <b>Demo</b> and <b>Codes</b>.
<li><b>More approaches to be added...</b></li>
</ul></ul></ul>
</pre></div></ul></ul>
<b>e. AJAX is bypassing the browser's form submission functionality</b>
<ul><ul><li>The Problem</li>(<a id="Be1"href="javascript:void(0)" onclick="divExpand(this);return false;" onMouseover="showtip()" onMouseout="hidetip()" style="text-decoration:none"></a>):
<div id="d_Be1" style="display:none;background-color:#CCFFFF;border-style: inset;width:1200"><pre>
Similarly, it is in javascript's namespace when preparing parameters for submission.
</pre></div>
<li>Solutions</li>(<a id="Be2" href="javascript:void(0)" onclick="divExpand(this);return false;" onMouseover="showtip()" onMouseout="hidetip()" style="text-decoration:none"></a>):
<div id="d_Be2" style="display:none;background-color:#CCFFFF;border-style: inset;width:1200"><pre>
<ul><ul><ul>
<li><b>AJAX</b></li>
So you need to extract fields from the form to be submit and construct your
parameter list before invoking XMLHttpRequest. You can always write a "cool"
generic method to handle most forms but again, you duplicate the form code.
Here are <b>Demo</b> and <b>Codes</b>.
<li><b>Dynamic hidden iFrame</b></li>
This problem is not a problem to iframes since you never touch fields in the form.
You only need to point the target of the form to the hidden iframe and
nothing redundent.
Here are <b>Demo</b> and <b>Codes</b>.
<li><b>Hidden frame</b></li>
Similar to the iframe approach.
Here are <b>Demo</b> and <b>Codes</b>.
<li><b>More approaches to be added...</b></li>
</ul></ul></ul>
</pre></div></ul></ul>
<b>f. AJAX could be turn off in some major browser like IE (6.x)</b>
<ul><ul><li>The Problem</li>(<a id="Bf1" href="javascript:void(0)" onclick="divExpand(this);return false;" onMouseover="showtip()" onMouseout="hidetip()" style="text-decoration:none"></a>):
<div id="d_Bf1" style="display:none;background-color:#CCFFFF;border-style: inset;width:1200"><pre>
AJAX is not a native component in some browsers and users may disable it.
For example, AJAX appears in IE as an ActiveX, an embedded object. Users or
security application can disable it in the "Script ActiveX controls marked
safe for scripting" from the "internet option" of control panel in Windows.
Actually, a lots of companies will have ActiveX controls disabled and many
PC protection programs also make turning off ActiveX at one of their security
level.
If your users are the "very end" users like shopping people using
IE to access your shopping carts, using AJAX is really gambling.
You are bidding on them with ActiveX on to see your AJAX pages.
Even though IE 7.x makes XMLHttpRequest a native component but it can still
be turn off.
</pre></div>
<li>Solutions</li>(<a id="Bf2" href="javascript:void(0)" onclick="divExpand(this);return false;" onMouseover="showtip()" onMouseout="hidetip()" style="text-decoration:none"></a>):
<div id="d_Bf2" style="display:none;background-color:#CCFFFF;border-style: inset;width:1200"><pre>
<ul><ul><ul>
<li><b>AJAX</b></li>
You may want to detect the situation and work around.
Here are <b>Demo</b> and <b>Codes</b>.
<li><b>Dynamic hidden iFrame</b></li>
This problem is not a problem to iframes event though there is an item under
"Security Setting" named "Launching programs and files in an IFRAME".
It doesn't seem to work in IE6.
Here are <b>Demo</b> and <b>Codes</b>.
<li><b>Hidden frame</b></li>
This problem is not a problem to traditional frames at all.
Here are <b>Demo</b> and <b>Codes</b>.
<li><b>More approaches to be added...</b></li>
</ul></ul></ul>
</pre></div></ul></ul>
<b>g. More "AJAX doesn't have" features to be added...</b>
</font></pre>
<script language="javascript" src="/html/js/cross_browser.js"></script>
<script language="javascript" src="/html/js/include_ajax.js"></script>
<script id="__include__">
include.load("http://www.coolshare.com/html/common/contact.htm");
</script>
</body>
</html>