Why and how to build an AJAX application?
(By Mark Qian on 9/6/2006)
PREFACE
I felt a little bit sorry for Remote Scripting about using "AJAX" in the title because what I really
meant was Remote Scripting. In all my articles below, as you can see, I mostly use my Communicator
to handle the communication to server. My Communicator always provides 5 ways to communicate while AJAX
is only one of them, a small piece within the Remote Scripting territory.
"AJAX" or "Remote Scripting" only allows you to "asynchronizely" communicate with servers and carry out
the communication with AJAX is very simple:
- create an AJAX object
- make a call to the server given a callback handler
- process the response in your handler.
But there is a long way between "AJAX" and "AJAX Applications": after obtaining this "easy-to-use" gun,
you may be wondering two things:
a). When might this thing shoot back on me?
b). Where should I shoot?
The goal of this collection of live-code articles is to discuss and answer these two questions.
First, let's take care the safty issue: when may AJAX cause problem?
Here are some: Show details
- Bring down scalability with high frequency of chatness to server
Just like a "easy-to-use" gun, AJAX is very easy to be over used. When this kind of over usage
is accumulated up to certain level, the "gun" starts pointing back. Remote scripting can
increase usability dramatically (like GoogleMap) but it is also costful. It is important
for an AJAX programmer to determent when and how much to use it, or find a trade-off point between
performance and usability. Before we look into more detail, let's take a look at some examples
- On-demand scrolling table
Unlike map, table on have one dimension of panning but sometimes big number of columns.
Scrolling table won't give users as much pleasure as scrolling maps but scrolling table
may sometimes appear heavier than scrolling maps.
You can imagine how you servers/db will stress when thousands of users scroll simutaneosly.
Is On-demand scrolling table a good idea? Find out yourself here.
- Lost of browsing history
See details about browser history
- Security Issues
Remote Scriting offers many benefits to web communication: it can "silently" communicate with servers, it allows you to
communicate with servers in the same domain or different domains and so on. But at the same time, these benefits can also
be the "back door" of your security to hackers. Here are some typical ones:
- "Silently" communicate with server
Ajax allows you to send request and get response without reloadinng the page. This means, to hackers,
that someone can inject javascript onto a page and "silently" make some transactions without the knowledge
of the user who is viewing the page. Samy's AJAX Worm is one typical example. The javascript he injected to
his profile page in MySpace.com makes several transactions to add himself into the visitor's friend
list after obtaining the user's id while none never realized that since it is done in AJAX: no page repainting.
- Violation of "the same origin"
Remote Scriting (script tag approach) can break the "the same origin" rule so that hackers can communicate
to any domain. For example, they can send what they steal, like cookies, back to any server they want.
- More to come...
Show details
- What is really AJAX?
It isn't called AJAX but Remote Scripting.
-- a "gun" that can either shoot at you or your enemy...
Snapshots of the article: Show details
"...It seems that the word "AJAX" has been flooded everywhere these days when people
are talking about web development. People use "AJAX" to label a much bigger
territory, Remote Scripting. If you think AJAX is as "simple" as
- create a XMLHttpRequest Object
- make a call with callback handler
- handle server response in the handler
you are wrong..." See why here
- Why do we use AJAX?
I think that there two major reasons to use AJAX:
A. improve usability Show details
Communication with reloading entire web pages let users feel that they are using a "web" application instead
of a windows application since reloading pages will cause
- Empty pages appear before new content is shown up. See example.
- screen state lost See details.
- Longer waiting period after an user action since
1. browser always send back the entire form: more data to send and more data to be parsed by the server;
2. server always respond back entire pages that include not only state data but also static data which is
already loaded once and browser needs to reder to same data repeatly.
- Client-side states such as cursor position and focus field is lost after reloading by default.
- Useless history is recorded. See the example
With AJAX (or Remote Scripting), we can
- Eliminate Empty pages by submiting requests in "silent" ways. Here is an example for form submission.
- preserve screen state since the page is never reloaded
- reduce waiting period after an user action by
1. submiting only modified state data
2. returning and render part of page where state is changed.
- Client-side states such as cursor position and focus field never get lost sicne we never reloading pages.
(we may lost the state on the updated area but it is easier to restore since we know where)
- No useless history is recorded. See the example
- In some cases, AJAX is a necessary solution. See the example
Show details
Here we are back to the "gun" issue when talking about scalability. "Will AJAX increase or reduce scalability?" is similar to
"Will this thing(gun) kill enemy or me?". Of course, the answer is either depending how you use it or your goals.
In some cases, use of AJAX will bring you positive effect such as what I memtioned above. It can eliminate the redundent
page level reload by partially request and update exactly what we need. Here is one of common example:
A common "waste" from most popular application frameworks is that they have user communicate with server almost 100%.
Let's take look at ASP.NET (similar to JSF). ASP.NET (I mean, the default way, ASP.NET and many other framework now are "made up with "ajax" addition)
provides a "cool" event framework/system so that most events trigged by users at the browser can be sent/wired to the handlers at the server.
In this way, most user activity will cause entire page loads. This will dramatically impact the scalability. Furthermore, in some case,
it is hard to archive your goal with entire page load since you can't reload a page before you complete it without losing incompleted data
because of validation. See the "Dependent sections" example here.
With Ajax, we normally only load each page entirely once and then partially update the page as need.
But you need to realize that there may be some dark side on Ajax: in other cases, it may increase the frequency of chatness with server.
One example is on-demand table.
It looks "cool" but you can imagine what will happen when thousands of users scroll at the same time...
but this is the choice of Google Map. That is why I said "...also depends on your goals". On a map,
a "whole sale" style doesn't work since it takes longer to load and users most likely will only pay
attention on a limited area (with help of zooming) so the "retail" style should be used. But Google still pays for a better usability
by facing a high server load and a high bandwidth consumption.
Comparing to a map, a table will unlikely gain much user appreciation from the on-demand feature since
table only have one dimension to pan/scroll instead of two in a map and a table sometimes is heavier than a map in case
the table has a lot of columns. So it is not worth to provide on-demand for tables - my 2 cents.
When the accumulation of chatness to server reach certain level, the "gun" turns...
- Define the AJAX zones
The fundamental strategy of AJAX is eliminating entire page reload when user do interaction on the page.
That is, the page should be designed to communicate with users by replacing "zones" on the page until
it is necessary to load another page for next business-communication phase. One of typical example is
the page with depend sections where what to display on next zone is determent by value of a field in
current zone. See details at Dependent sections
So one of the most initial and important design phase is defining "asynchronizely
updating zones".
Here are some typical "AJAX Zone" candidates:
A.How to submit a form "silently"
Snapshots of the article: Show details
"... A major goal using AJAX (precisely, Remote Scripting) is to minimize page
reload. Form submission is the major way to communicate with server in a traditional web
page. Let's take a look at a concrete and very common example..."
"...In some pages, the form is only a small section. Reloading the entire page
not only load the new content for the form but also reload the rest of the page
(unchanged content). It cost more server cpu time to republish them and cost
network bandwidth to transfer them..." See details here
"...In some situation, such as my example "Silent Form" and on-demand tree, you can optionally
use Remote Scripting to do a better job. But in some other cases, you have to use it otherwise it is
hard to solve the problem. Dependent section is one of these cases..." See details here
"...Tables are most important web components, specially in data-rich applications.
Remote Scripting provides us an alternative to transfer data in a different
manner: on-demand data loading. You may want to take look at my article as an analysis
about how scrollbars of tables impact scalability..." See details here
"... Trees are commonly used components to represent Hierarchies. Traditionally, on-demand trees
are reloaded entirely when new content needs to be added. Remote Scripting allows
trees to be updated "silently" without reloading. The goal of this demostration is to show
how Remote Scripting can be used to build on-demand trees in a variety of ways
using Mark's Communicator..." See details here
"...AutoSuggest Text Box become more and more popular, specially after AJAX is available.
The GUI appearance is kind of "new" but the concept has been around for a long time.
I used to work on the AR WebPlus in Remedy ten years ago (around 1996) and did page
level of "Auto-complete" with hidden frame. The goal of this demostration is to show
how Remote Scripting can be used to build an AutoSuggest in a variety of ways
using Mark's Communicator as the mean of communication..." See details here
"... Client-side Include or Html Include is an operation that adds pieces of desired/shared html to the
target page(s), at render time in the browser instead of on the server. It is useful when you don't
have or don't want to use Server-side Include. There are a variety of ..." See details here
"... Session timeout client-side notification has always been an issue in web development.
Many application just make it a "user-self-checking" manner. That is, users have no idea
about the http session is timeout until they make their first submission after the session
timeout. Usability is low in this way: users may enter a lot of data without realizing
the session is timeout and may lose all the data they enter in case the form is not
cached locally.
With AJAX+Javascript, Session timeout notification made easy...." See details here
- Design pattern and strategy
Remote Scripting makes a big space available for web application to be improved and expanded. There are
a variety of approaches, pattern and strategies. I will discuss some of the design strategies that I used, specially
focusing on scalability.
A. How to access objects in server from javascript namespace
a. Under Spring MVC
Snapshots of the article: Show details
"... To build an "AJAX application", the first design issue you face after loading a page is "how to access
backend objects from javascript namespace where you make ajax calls?" ..." See details here
"... In early days, web publish was static and simple: browsers fetched static html files from servers,
displayed them, cached them and never fetched them again. The web world was changed after
"dynamic" publish kicked in: we didn't cache pages any more; just like enjoying vegetable and fruit,
we mostly got "fresh" pages from server again and again. The result is that we suddently face
heavy server load and much more bandwidth requirement.
Can we go back to the simple life: load once and never load again? The answer is ..." See details here
"... There are many static areas in dynamic published pages. These static areas (for example, they are called
"tiles" in Struts) appear as headers, nevigation and footers. The same static areas are combined with dynamic
data into pages in server side and published back to browsers ..." See details here
|