Are there Usability Issues with AJAX?
The nature of updating a page dynamically using data
retrieved via AJAX interactions and DHTML may result in
drastically changing the appearance and state of a page.
A user might choose to use the browser's back or forward
buttons, bookmark a page, copy the URL from the URL bar
and share it with a friend via an email or chat client,
or print a page at any given time. When designing an
AJAX based application you need to consider what the
expected behavior would be in the case of navigation,
bookmarking, printing, and browser support as described
below.
* Navigation - What would be the expected behavior of
the back, forward, refresh, and bookmark browser buttons
in your application design. While you could implement
history manipulation manually it may be easer to use a
JavaScript frameworks such as Dojo that provides API's
history manipulation and navigation control.
* Bookmarking and URL sharing - Many users want to
bookmark or cut and paste the URL from the browser bar.
Dojo provides client-side for bookmarking and URL
manipulation.
* Printing - In some cases printing dynamically rendered
pages can be problematic.
Other considerations as a developer when using AJAX are:
* Browser Support - Not all AJAX/DHTML features are
supported on all browsers or all versions of a browser.
See quirksmode.org for a list of browser support and
possible workarounds.
* JavaScript disabled - You should also consider what
happens if the user disables JavaScript. Additionally,
there are several legitimate reasons why JavaScript and
CSS support may be unavailable on a user's web browser.
* Latency - Keep in mind latency in your design. A
running application will be much more responsive than
when it is deployed.
Latency problems: myth or reality?
* Accessibility - Guaranteeing your site is accessible
to people with disabilities is not only a noble goal, it
is also requited by law in many markets. Some marvelous
enabling technology is available to help people use the
Web in spite of disabilities including visual, auditory,
physical, speech, cognitive, and neurological
disabilities. With a little forethought, and
comprehension of some well documented best practices,
you can assure that your application is compatible with
that enabling technology.
Degradability is the term used to describe techniques
used by web applications to adapt to the wide range of
web browser capabilities. Many AJAX libraries have
automatic degradability built in. But if you are coding
your own custom AJAX functionality, simply taking some
care to follow the best practices promoted by standards
bodies like the World Wide Web Consortium (W3C), and
grass root movements like the Web Standards community
and many others, your application can run usefully on
browsers that are incapable of AJAX behaviors. Granted,
your application may loose some of the "wow factor" on
these less capable browsers, but your application will
still be usable.
Remember to not design with AJAX just for the sake of
coolness. The reason you built your application is so
people will use it. And people will not use your
application if your application is not compatible with
their web browser.
Are there any frameworks available to help speedup
development with AJAX?
There are several browser-side frameworks available,
each with their own uniqueness...
Is Adaptive Path selling Ajax components or trademarking
the name? Where can I download it?
Ajax isn’t something you can download. It’s an approach
— a way of thinking about the architecture of web
applications using certain technologies. Neither the
Ajax name nor the approach are proprietary to Adaptive
Path.
Should I use an HTTP GET or POST for my AJAX calls?
AJAX requests should use an HTTP GET request when
retrieving data where the data will not change for a
given request URL. An HTTP POST should be used when
state is updated on the server. This is in line with
HTTP idempotency recommendations and is highly
recommended for a consistent web application
architecture.
How do I debug JavaScript?
There are not that many tools out there that will
support both client-side and server-side debugging. I am
certain this will change as AJAX applications
proliferate. I currently do my client-side and
server-side debugging separately. Below is some
information on the client-side debuggers on some of the
commonly used browsers.
* Firefox/Mozilla/Netscape - Have a built in debugger
Venkman which can be helpful but there is a Firefox add
on known as FireBug which provides all the information
and AJAX developer would ever need including the ability
to inspect the browser DOM, console access to the
JavaScript runtime in the browser, and the ability to
see the HTTP requests and responses (including those
made by an XMLHttpRequest). I tend to develop my
applications initially on Firefox using Firebug then
venture out to the other browsers.
* Safari - Has a debugger which needs to be enabled. See
the Safari FAQ for details.
* Internet Explorer - There is MSDN Documentation on
debugging JavaScript. A developer toolbar for Internet
Explorer may also be helpful.
While debuggers help a common technique knowing as
"Alert Debugging" may be used. In this case you place
"alert()" function calls inline much like you would a
System.out.println. While a little primitive it works
for most basic cases. Some frameworks such as Dojo
provide APIs for tracking debug statements.
How do I provide internationalized AJAX interactions?
Just because you are using XML does not mean you can
properly send and receive localized content using AJAX
requests. To provide internationalized AJAX components
you need to do the following:
* Set the charset of the page to an encoding that is
supported by your target languages. I tend to use UTF-8
because it covers the most languages. The following meta
declaration in a HTML/JSP page will set the content
type:
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
* In the page JavaScript make sure to encode any
parameters sent to the server. JavaScript provides the
escape() function which returns Unicode escape strings
in which localized text will appear in hexadecimal
format. For more details on JavaScript encoding see
Comparing escape(), encodeURI(), and encodeURIComponent().
* On the server-side component set the character
encoding using the
HttpServletRequest.setCharacterEncoding() method. Before
you access the localized parameter using the
HttpServletRequest.getParameter() call. In the case of
UTF this would be request.setCharactherEncoding("UTF-8");.
A server-side component returning AJAX responses needs
to set the encoding of the response to the same encoding
used in the page.
response.setContentType("text/xml;charset=;UTF-8");
response.getWriter().write(" <response>invalid
</response>");
For more information on using AJAX with Java Enterprise
Edition technologies see AJAX and Internationalization
and for developing multi-lingual applications see
Developing Multilingual Web Applications Using
JavaServer Pages Technology.
Some of the Google examples you cite don’t use XML at
all. Do I have to use XML and/or XSLT in an Ajax
application?
No. XML is the most fully-developed means of getting
data in and out of an Ajax client, but there’s no reason
you couldn’t accomplish the same effects using a
technology like JavaScript Object Notation or any
similar means of structuring data for interchange.
Are Ajax applications easier to develop than traditional
web applications?
Not necessarily. Ajax applications inevitably involve
running complex JavaScript code on the client. Making
that complex code efficient and bug-free is not a task
to be taken lightly, and better development tools and
frameworks will be needed to help us meet that
challenge.
When do I use a synchronous versus a asynchronous
request?
Good question. They don't call it AJAX for nothing! A
synchronous request would block in page event processing
and I don't see many use cases where a synchronous
request is preferable.
