Explore topic-wise InterviewSolutions in Current Affairs.

It’s both. AJAX is a SET of technologies being USED together in a PARTICULAR WAY.

It’s both. Ajax is a set of technologies being used together in a particular way.

What’s new is the prominent use of these techniques in real-world applications to change the fundamental interaction model of the WEB. AJAX is TAKING hold now because these technologies and the INDUSTRY’s understanding of how to deploy them most effectively have taken time to DEVELOP.

What’s new is the prominent use of these techniques in real-world applications to change the fundamental interaction model of the Web. Ajax is taking hold now because these technologies and the industry’s understanding of how to deploy them most effectively have taken time to develop.

Not TOTALLY. Most browsers offer a native XMLHttpRequest JavaScript object, while ANOTHER one (Internet EXPLORER) REQUIRE you to get it as an ActiveX object....

Not totally. Most browsers offer a native XMLHttpRequest JavaScript object, while another one (Internet Explorer) require you to get it as an ActiveX object....

Don't be too quick to dump your PLUGIN or applet based PORTIONS of your application. While AJAX and DHTML can do drag and drop and other advanced user interfaces there still limitations especially when it comes to browser support. Plugins and applets have been around for a while and have been able to make AJAX like requests for years. Applets provide a great set of UI COMPONENTS and APIs that provide developers literally anything.

Many people disregard applets or plugins because there is a startup time to initialize the plugin and there is no guarantee that the needed version of a plugin of JVM is installed. Plugins and applets may not be as capable of manipulating the page DOM. If you are in a uniform environment or can depend on a specific JVM or plugin version being available (such as in a corporate environment) a plugin or applet solution is great.

One THING to consider is a mix of AJAX and applets or plugins. Flickr uses a ombination of AJAX interactions/DHTML for labeling pictures and user interaction and a plugin for manipulating photos and photo sets to provide a great user experience. If you design your server-side components well they can talk to both types of clients.

Don't be too quick to dump your plugin or applet based portions of your application. While AJAX and DHTML can do drag and drop and other advanced user interfaces there still limitations especially when it comes to browser support. Plugins and applets have been around for a while and have been able to make AJAX like requests for years. Applets provide a great set of UI components and APIs that provide developers literally anything.

Many people disregard applets or plugins because there is a startup time to initialize the plugin and there is no guarantee that the needed version of a plugin of JVM is installed. Plugins and applets may not be as capable of manipulating the page DOM. If you are in a uniform environment or can depend on a specific JVM or plugin version being available (such as in a corporate environment) a plugin or applet solution is great.

One thing to consider is a mix of AJAX and applets or plugins. Flickr uses a ombination of AJAX interactions/DHTML for labeling pictures and user interaction and a plugin for manipulating photos and photo sets to provide a great user experience. If you design your server-side components well they can talk to both types of clients.

JavaScript is in plain VIEW to the user with by selecting view source of the page. JavaScript can not ACCESS the local FILE system WITHOUT the user's permission. An AJAX interaction can only be made with the servers-side component from which the page was loaded. A proxy pattern could be used for AJAX interactions with external services.

You need to be careful not to expose your application model in such as way that your server-side components are at risk if a nefarious user to reverse engineer your application. As with any other web application, CONSIDER using HTTPS to secure the connection when confidential information is being exchanged.

JavaScript is in plain view to the user with by selecting view source of the page. JavaScript can not access the local file system without the user's permission. An AJAX interaction can only be made with the servers-side component from which the page was loaded. A proxy pattern could be used for AJAX interactions with external services.

You need to be careful not to expose your application model in such as way that your server-side components are at risk if a nefarious user to reverse engineer your application. As with any other web application, consider using HTTPS to secure the connection when confidential information is being exchanged.

DEPENDING UPON the BROWSER...

Depending upon the browser...

If you run into an HTML_AJAX problem only on some servers, chances are your running into a problem with output compression. If the output compression is handled in the PHP config we detect that and do the right thing, but if its done from an apache extension we have no way of knowing its going to compress the body. Some TIMES setting HTML_AJAX::sendContentLength to false fixes the problem, but in other cases you'll need to disabled the extension for the AJAX pages.

I've also SEEN PROBLEMS caused by DEBUGGING extensions like XDebug, disabling the extension on the server page usually fixes that. QUESTIONS dealing with Using HTML_AJAX, and general JavaScript development

If you run into an HTML_AJAX problem only on some servers, chances are your running into a problem with output compression. If the output compression is handled in the PHP config we detect that and do the right thing, but if its done from an apache extension we have no way of knowing its going to compress the body. Some times setting HTML_AJAX::sendContentLength to false fixes the problem, but in other cases you'll need to disabled the extension for the AJAX pages.

I've also seen problems caused by debugging extensions like XDebug, disabling the extension on the server page usually fixes that. Questions dealing with Using HTML_AJAX, and general JavaScript development

The oldest PHP VERSION i've FULLY tested HTML_AJAX is 4.3.11, but it should run on 4.2.0 without any problems. (Testing reports from PHP versions OLDER then 4.3.11 WOULD be appreciated.)

The oldest PHP version i've fully tested HTML_AJAX is 4.3.11, but it should run on 4.2.0 without any problems. (Testing reports from PHP versions older then 4.3.11 would be appreciated.)

Just CALL the ABORT() METHOD on the REQUEST.

Just call the abort() method on the request.

No. XMLHTTPREQUEST is only part of the Ajax EQUATION. XMLHttpRequest is the technical COMPONENT that makes the ASYNCHRONOUS server communication possible; Ajax is our NAME for the overall approach described in the article, which relies not only on XMLHttpRequest, but on CSS, DOM, and other technologies.

No. XMLHttpRequest is only part of the Ajax equation. XMLHttpRequest is the technical component that makes the asynchronous server communication possible; Ajax is our name for the overall approach described in the article, which relies not only on XMLHttpRequest, but on CSS, DOM, and other technologies.

It depends. With AJAX the answer is more in between. Control can be more centralized in a server-side component or as a mix of client-side and server-side CONTROLLERS.

1. Centralized server-side controller - When having a more centralized controller the KEY is to make sure the data in client-side page is in sync with that of the server. Some applications may keep all the state on the server and push all UPDATES to client DOM via a simple JavaScript controller.
2. Client and server-side controllers - This architecture would use JavaScript to do all presentation related control, event processing, page manipulation, and rendering of model data on the client. The server-side would be responsible for things such as business logic and pushing updated model data to the client. In this case the server would not have intimate knowledge of the presentation short of the initial page that would be sent to the client page request.

There are some use cases where an entire AJAX application can be written in a SINGLE page. Keep in mind if you choose this type of architecture that NAVIGATION and bookmarking should be considered.

Both methods are viable depending on what you are trying to accomplish. I tend to prefer spreading the control across the client and server.

It depends. With AJAX the answer is more in between. Control can be more centralized in a server-side component or as a mix of client-side and server-side controllers.

There are some use cases where an entire AJAX application can be written in a single page. Keep in mind if you choose this type of architecture that navigation and bookmarking should be considered.

Both methods are viable depending on what you are trying to accomplish. I tend to prefer spreading the control across the client and server.

We don't have a list right now, but most of the API is stable ASAS of 0.3.0, all the EXAMPLES that ship with HTML_AJAX have been verified to work with

1. Firefox 1.0+
2. Internet EXPLORER 5.5+ (5.0 should work but it hasn't been tested)

Most things work with

1. Safari 2+
2. Opera 8.5+ of 0.3.0. There should be no major changes at this point, THOUGH there will be LOTS of new additions.

We don't have a list right now, but most of the API is stable asAs of 0.3.0, all the examples that ship with HTML_AJAX have been verified to work with

Most things work with

We don't have a LIST right now, but most of the API is stable as of 0.3.0. There should be no major changes at this POINT, THOUGH there will be lots of new additions.

We don't have a list right now, but most of the API is stable as of 0.3.0. There should be no major changes at this point, though there will be lots of new additions.

Once all the major FEATURES are complete and the API has been tested, the roadmap GIVES an idea of what is LEFT to be done.

Once all the major features are complete and the API has been tested, the roadmap gives an idea of what is left to be done.

The W3C DOCUMENT Object Model (DOM) is DEFINED by the W3C as the following: The Document Object Model is a PLATFORM- and language-neutral interface.

The W3C Document Object Model (DOM) is defined by the W3C as the following: The Document Object Model is a platform- and language-neutral interface.

There is a PORT of JUNIT for client-side JAVASCRIPT CALLED JsUnit.

There is a port of JUnit for client-side JavaScript called JsUnit.

When creating a form make sure that the "form" element "onSubmit" attribute is SET to a JavaScript function that returns false. 

You can ALSO submit data by associating a function with a form button in a similar way.

Note that the form "onSubmit" attribute is still set. If the USER hits the enter key in the text field the form will be submitted so you still need to HANDLE that case.

When updating the page it is recommend you wait to make sure that the AJAX update of the form data was successful before updating the data in the page. OTHERWISE, the data may not properly update and the user may not know. I like to provide an informative message when doing a partial update and upon a successful AJAX interaction I will then update the page.

When creating a form make sure that the "form" element "onSubmit" attribute is set to a JavaScript function that returns false. 

You can also submit data by associating a function with a form button in a similar way.

Note that the form "onSubmit" attribute is still set. If the user hits the enter key in the text field the form will be submitted so you still need to handle that case.

When updating the page it is recommend you wait to make sure that the AJAX update of the form data was successful before updating the data in the page. Otherwise, the data may not properly update and the user may not know. I like to provide an informative message when doing a partial update and upon a successful AJAX interaction I will then update the page.

HTML_AJAX hasn't had a STABLE RELEASE yet and the pear INSTALLER doesn't install non stable PACKAGES by default unless you specify a version.

HTML_AJAX hasn't had a stable release yet and the pear installer doesn't install non stable packages by default unless you specify a version.

The "Content-Type" header needs to be set to"text/xml". In servlets this may be done using the HttpServletResponse.setContentType()should be set to "text/xml" when the return type is XML. Many XMLHttpRequest IMPLEMENTATIONS will RESULT in an error if the "Content-Type" header is set The code below shows how to set the "Content-Type".

You may also want to set whether or not to set the caches header for cases such as autocomplete where you may want to notify proxy servers/and browsers not to cache the results.

Note to the developer: Internet Explorer will automatically use a cached result of any AJAX response from a HTTP GET if this header is not set which can make THINGS difficult for a developer. During development mode you may want set this header. Where do I store state with an AJAX client

As with other browser based web applications you have a few options which include:

1. On the client in cookies - The size is limited (generally around 4KB X 20 cookies per domain so a total of 80KB) and the content may not be secure unless encrypted which is difficult but not impossible using JavaScript.
2. On the client in the page - This can be done securely but can be problematic and difficult to work with. See my blog entry on Storing State on the Client for more details on this topic.
3. On the client file system - This can be done if the client grants access to the browser to write to the local file system. Depending on your uses cases this may be necessary but caution is advised.
4. On the Server - This is closer to the traditional model where the client view is of the state on the server. Keeping the data in sync can be a bit problematic and thus we have a solution Refreshing Data on this. As more information processing and control MOVES to the client where state is stored will need to be re-evaluated.

The "Content-Type" header needs to be set to"text/xml". In servlets this may be done using the HttpServletResponse.setContentType()should be set to "text/xml" when the return type is XML. Many XMLHttpRequest implementations will result in an error if the "Content-Type" header is set The code below shows how to set the "Content-Type".

You may also want to set whether or not to set the caches header for cases such as autocomplete where you may want to notify proxy servers/and browsers not to cache the results.

Note to the developer: Internet Explorer will automatically use a cached result of any AJAX response from a HTTP GET if this header is not set which can make things difficult for a developer. During development mode you may want set this header. Where do I store state with an AJAX client

As with other browser based web applications you have a few options which include:

With JavaScript you can have more than one AJAX request processing at a single time. In order to insure the proper post processing of CODE it is recommended that you use JavaScript Closures. The example below shows an XMLHttpRequest object abstracted by a JavaScript object called AJAXInteraction. As ARGUMENTS you pass in the URL to call and the function to call when the processing is done.

The function makeRequest() in the example above creates an AJAXInteraction with a URL to of "processme" and an inline function that will show an alert dialog with the message "Doing Post Process". When ai.doGet() is called the AJAX interaction is initiated and when server-side component mapped to the URL "processme" returns a document which is passed to the callback function that was specified when the AJAXInteraction was created.

Using this closures insures that the proper callback function associated with a specific AJAX interaction is called. Caution should still be taken when CREATING multiple closure objects in that make XmlHttpRequests as to there is a limited number of sockets that are used to make requests at any given time. Because there are limited number of requests that can be made concurrently. Internet EXPLORER for example only allows for two concurrent AJAX requests at any given time. Other browsers may allow more but it is generally between three and five requests. You may choose to use pool of AJAXInteraction objects.

One thing to note when making multiple AJAX calls from the client is that the calls are not guaranteed to return in any given order. Having closures within the callback of a closure object can be used to ensure dependencies are processed correctly. There is a discussion titled Ajaxian Fire and Forget Pattern that is helpful.

With JavaScript you can have more than one AJAX request processing at a single time. In order to insure the proper post processing of code it is recommended that you use JavaScript Closures. The example below shows an XMLHttpRequest object abstracted by a JavaScript object called AJAXInteraction. As arguments you pass in the URL to call and the function to call when the processing is done.

The function makeRequest() in the example above creates an AJAXInteraction with a URL to of "processme" and an inline function that will show an alert dialog with the message "Doing Post Process". When ai.doGet() is called the AJAX interaction is initiated and when server-side component mapped to the URL "processme" returns a document which is passed to the callback function that was specified when the AJAXInteraction was created.

Using this closures insures that the proper callback function associated with a specific AJAX interaction is called. Caution should still be taken when creating multiple closure objects in that make XmlHttpRequests as to there is a limited number of sockets that are used to make requests at any given time. Because there are limited number of requests that can be made concurrently. Internet Explorer for example only allows for two concurrent AJAX requests at any given time. Other browsers may allow more but it is generally between three and five requests. You may choose to use pool of AJAXInteraction objects.

One thing to note when making multiple AJAX calls from the client is that the calls are not guaranteed to return in any given order. Having closures within the callback of a closure object can be used to ensure dependencies are processed correctly. There is a discussion titled Ajaxian Fire and Forget Pattern that is helpful.

 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.

 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.

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.

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.

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:

Step 1. 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:

Step 2.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 seeComparing escape(), encodeURI(), and encode URI Component().

Step 3. 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 .set Characther Encoding ("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.

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.

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:

Step 1. 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:

Step 2.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 seeComparing escape(), encodeURI(), and encode URI Component().

Step 3. 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 .set Characther Encoding ("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.

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.

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.

1. 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.
2. Safari - Has a debugger which needs to be enabled. See the Safari FAQ for details.
3. 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.

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.

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.

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 consistent web application ARCHITECTURE.

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 consistent web application architecture.

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 is PROPRIETARY to Adaptive Path.

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 is proprietary to Adaptive Path.

There are SEVERAL browser-side FRAMEWORKS AVAILABLE, each with their own UNIQUENESS...

There are several browser-side frameworks available, each with their own uniqueness...

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.

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.

Other considerations as a developer when using AJAX are:

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.

It depends. Clearly the 'X' in AJAX stands for XML, but several AJAX proponents are quick to point out that nothing in AJAX, per se, precludes using other types of payload, such as, JavaScript, HTML, or plain TEXT.

1. XML - Web Services and AJAX seem made for one another. You can use client-side API's for downloading and parsing the XML content from RESTful Web Services. (However be mindful with some SOAP based Web Services architectures he payloads can get QUITE large and complex, and therefore may be inappropriate with AJAX techniqes.)
2. Plain Text - In this case server-generated text may be INJECTED into a document or evaluated by client-side logic.
3. JavaScript - This is an extension to the plain text case with the exception that a server-side component passes a fragment of JavaScript including JavaScript object declarations. Using the JavaScript eval() function you can then CREATE the objects on the client. JavaScript Object Notation (JSON), which is a JavaScript object based data exchange specification, relies on this technique.
4. HTML - Injecting server-generated HTML fragments directly into a document is generally a very effective AJAX technique. However, it can be complicated keeping the server-side component in sync with what is displayed on the client.

MASHUP is a popular term for creating a completely new web application by combining the content from disparate Web Services and other online API's. A good example of a mashup is housingmaps.com which graphically combines housing want-ads from craiglist.org and maps from maps.google.com.

It depends. Clearly the 'X' in AJAX stands for XML, but several AJAX proponents are quick to point out that nothing in AJAX, per se, precludes using other types of payload, such as, JavaScript, HTML, or plain text.

Mashup is a popular term for creating a completely new web application by combining the content from disparate Web Services and other online API's. A good example of a mashup is housingmaps.com which graphically combines housing want-ads from craiglist.org and maps from maps.google.com.

Proxied calls are made through stub OBJECTS that mimic your PHP classes on the JavaScript side. E.g., the helloworld class from the Hello WORLD example.

Proxyless calls are made using utility javascript FUNCTIONS LIKE HTML_AJAX.replace() and HTML_AJAX.append().

Proxied calls are made through stub objects that mimic your PHP classes on the JavaScript side. E.g., the helloworld class from the Hello World example.

Proxyless calls are made using utility javascript functions like HTML_AJAX.replace() and HTML_AJAX.append().

There are many libraries/frameworks out there (and many more emerging) that will help abstract such things as all the nasty browser differences. Three good libraries are The Dojo Toolkit, Prototype, and DWR.

1. The Dojo Toolkit contains APIs and widgets to support the development of rich web applications. Dojo contains an intelligent packaging system, UI effects, drag and drop APIs, widget APIs, event abstraction, client storage APIs, and AJAX interaction APIs. Dojo solves common usability issues such as support for dealing with the navigation such as the ability to detect the browser back button, the ability to support changes to the URL in the URL bar for bookmarking, and the ability to gracefully degrade when AJAX/JavaScript is not fully support on the client. Dojo is the Swiss Army Knife of JavaScript libraries. It provides the widest range of options in a single library and it does a very good job supporting new and older browsers.
2. Prototype focuses on AJAX interactions including a JavaScript AJAX object that contains a few objects to do basic tasks such as MAKE a request, update a portion of a document, insert content into a document, and update a portion of a document periodically. Prototype JavaScript library contains a set of JavaScript objects for representing AJAX requests and contains utility FUNCTIONS for accessing in page components and DOM manipulations. Script.aculo.us and Rico are BUILT on top of Prototype and provide UI effects, support for drag and drop, and include common JavaScript centric widgets. If you are just looking to support AJAX interactions and a few basic tasks Prototype is great. If you are looking for UI effects Rico and Script.aculo.us are good options.
3. DWR (Dynamic Web Remoting) is a client-side and server-side framework that focuses on allowing a developer to do RPC calls from client-side JavaScript to plain old Java objects in a Java Enterprise Edition web container. On the server side DWR uses a Servlet to interact with the Java objects and returns object representations of the Java objects or XML documents. DWR will be easy to get up and running and plays well with other Java technologies. If you are looking for a client-side and server-side framework that integrates well use DWR.

There are many new and emerging libraries for JavaScript and this list only reviews some of the more common libraries. When making a choice choose the library which suites your needs the BEST. While it might be better to choose one, there is nothing STOPPING you from using more than one framework. For a more extensive list of client-side frameworks see: Survey of AJAX/JavaScript Libraries.

There are many libraries/frameworks out there (and many more emerging) that will help abstract such things as all the nasty browser differences. Three good libraries are The Dojo Toolkit, Prototype, and DWR.

There are many new and emerging libraries for JavaScript and this list only reviews some of the more common libraries. When making a choice choose the library which suites your needs the best. While it might be better to choose one, there is nothing stopping you from using more than one framework. For a more extensive list of client-side frameworks see: Survey of AJAX/JavaScript Libraries.

If you plan not to reuse and existing AJAX component, here are some of the THINGS you will need to know.

1. Plan to learn Dynamic HTML (DHTML), the technology that is the foundation for AJAX. DHTML enables browser-base real time interaction between a user and a web page. DHTML is the combination of JavaScript, the Document OBJECT Model (DOM) and Cascading Style Sheets (CSS).
2. JavaScript - JavaScript is a loosely typed object based scripting language supported by all MAJOR browsers and essential for AJAX interactions. JavaScript in a page is called when an event in a page occurs such as a page load, a mouse click, or a key press in a form element.
3. DOM - An API for accessing and manipulating structured documents. In most cases DOM represent the structure of XML and HTML documents.
4. CSS - Allows you to define the presentation of a page such as fonts, colors, sizes, and positioning. CSS allow for a clear separation of the presentation from the content and may be changed PROGRAMMATICALLY by JavaScript.

Understanding the basic request/response nature of HTTP is also important. Many subtle bugs can result if you ignore the differences between the GET and OIst methods when configuring an XMLHttpRequest and HTTP response codes when processing callbacks.

JavaScript is the client-side glue, in a sense. JavaScript is used to create the XMLHttpRequest Object and trigger the asynchronous call. JavaScript is used to parse the returned content. JavaScript is used to analyze the returned data and process returned MESSAGES. JavaScript is used to inject the new content into the HTML using the DOM API and to modify the CSS.

If you plan not to reuse and existing AJAX component, here are some of the things you will need to know.

Understanding the basic request/response nature of HTTP is also important. Many subtle bugs can result if you ignore the differences between the GET and OIst methods when configuring an XMLHttpRequest and HTTP response codes when processing callbacks.

JavaScript is the client-side glue, in a sense. JavaScript is used to create the XMLHttpRequest Object and trigger the asynchronous call. JavaScript is used to parse the returned content. JavaScript is used to analyze the returned data and process returned messages. JavaScript is used to inject the new content into the HTML using the DOM API and to modify the CSS.

This is working code, it might help you.
if (!ISIE)
xmldoc = req.RESPONSEXML;
else
{
//IE does not take the responseXML as.

This is working code, it might help you.
if (!isIE)
xmldoc = req.responseXML;
else
{
//IE does not take the responseXML as.

It's not POSSIBLE to set any session variables DIRECTLY from JAVASCRIPT as it is purely a client side technology. You can use AJAX though to asynchronously...

It's not possible to set any session variables directly from javascript as it is purely a client side technology. You can use AJAX though to asynchronously...

Neither Adaptive Path nor Google invented AJAX. Google’s recent PRODUCTS are simply the highest-profile examples of Ajax applications. Adaptive Path was not INVOLVED in the development of Google’s Ajax applications, but we have been doing Ajax WORK for some of our other clients.

Neither Adaptive Path nor Google invented Ajax. Google’s recent products are simply the highest-profile examples of Ajax applications. Adaptive Path was not involved in the development of Google’s Ajax applications, but we have been doing Ajax work for some of our other clients.

You may be benefiting from AJAX already. Many EXISTING JAVA BASED frameworks already have some level of AJAX interactions and new frameworks and component libraries are being developed to provide better AJAX support. I won't list all the Java frameworks that use AJAX here, out of fear of missing SOMEONE, but you can find a good list at www.ajaxpatterns.org/Java_Ajax_Frameworks.

If you have not chosen a framework yet it is recommended you consider using JavaServer Faces or a JavaServer Faces based framework. JavaServer Faces components can be created and used to abstract many of the details of GENERATING JavaScript, AJAX interactions, and DHTML processing and thus enable simple AJAX used by JSF application developer and as plug-ins in JSF compatible IDE's, such as Sun Java Studio Creator.

You may be benefiting from AJAX already. Many existing Java based frameworks already have some level of AJAX interactions and new frameworks and component libraries are being developed to provide better AJAX support. I won't list all the Java frameworks that use AJAX here, out of fear of missing someone, but you can find a good list at www.ajaxpatterns.org/Java_Ajax_Frameworks.

If you have not chosen a framework yet it is recommended you consider using JavaServer Faces or a JavaServer Faces based framework. JavaServer Faces components can be created and used to abstract many of the details of generating JavaScript, AJAX interactions, and DHTML processing and thus enable simple AJAX used by JSF application developer and as plug-ins in JSF compatible IDE's, such as Sun Java Studio Creator.

Basically yes if you plan to develop new AJAX functionality for your web application. On the other hand, JSF components and component libraries can abstract the DETAILS of JavaScript, DOM and CSS. These components can generate the necessary artifacts to make AJAX interactions possible. Visual TOOLS such as Java Studio Creator may also use AJAX enabled JSF components to create applications, shielding the tool DEVELOPER from many of the details of AJAX. If you plan to develop your own JSF components or wire the events of components together in a tool it is important that you have a basic understanding of JavaScript. There are client-side JavaScript libraries (discussed below) that you can call from your in page JavaScript that abstract browser differences. Object HIERARCHY and INHERITANCE in JavaScript is a great resource for a Java developer to learn about JavaScript objects.

Basically yes if you plan to develop new AJAX functionality for your web application. On the other hand, JSF components and component libraries can abstract the details of JavaScript, DOM and CSS. These components can generate the necessary artifacts to make AJAX interactions possible. Visual tools such as Java Studio Creator may also use AJAX enabled JSF components to create applications, shielding the tool developer from many of the details of AJAX. If you plan to develop your own JSF components or wire the events of components together in a tool it is important that you have a basic understanding of JavaScript. There are client-side JavaScript libraries (discussed below) that you can call from your in page JavaScript that abstract browser differences. Object Hierarchy and Inheritance in JavaScript is a great resource for a Java developer to learn about JavaScript objects.

Absolutely. Java is a great FIT for AJAX! You can use Java ENTERPRISE Edition servers to generate AJAX CLIENT pages and to serve incoming AJAX requests, manage server SIDE state for AJAX clients, and connect AJAX clients to your enterprise resources. The JavaServer Faces component MODEL is a great fit for defining and using AJAX components.

Absolutely. Java is a great fit for AJAX! You can use Java Enterprise Edition servers to generate AJAX client pages and to serve incoming AJAX requests, manage server side state for AJAX clients, and connect AJAX clients to your enterprise resources. The JavaServer Faces component model is a great fit for defining and using AJAX components.

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.

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.

Not necessarily. Ajax gives interaction designers more flexibility. HOWEVER, the more POWER we have, the more CAUTION we must use in exercising it. We must be careful to use Ajax to ENHANCE the user experience of our applications, not degrade it.

Not necessarily. Ajax gives interaction designers more flexibility. However, the more power we have, the more caution we must use in exercising it. We must be careful to use Ajax to enhance the user experience of our applications, not degrade it.

Assuming the framework you are using does not SUFFICE your use cases and you would like to develop your own AJAX components or functionality I suggest you start with the ARTICLE Asynchronous JavaScript Technology and XML (AJAX) With Java 2 PLATFORM, Enterprise Edition. If you would like to see a very basic example that includes source code you can check out the tech tip Using AJAX with Java Technology. For a more complete list of AJAX resources the Blueprints AJAX Home page.Next, I would recommend spending some time investigating AJAX libraries and frameworks. If you choose to write your own AJAX clients-side script you are much better off not re-inventing the wheel.

AJAX in ACTION by Dave Crane and Eric Pascarello with Darren James is GOOD resource. This book is helpful for the Java developer in that in contains an appendix for learning JavaScript for the Java developer.

Assuming the framework you are using does not suffice your use cases and you would like to develop your own AJAX components or functionality I suggest you start with the article Asynchronous JavaScript Technology and XML (AJAX) With Java 2 Platform, Enterprise Edition. If you would like to see a very basic example that includes source code you can check out the tech tip Using AJAX with Java Technology. For a more complete list of AJAX resources the Blueprints AJAX Home page.Next, I would recommend spending some time investigating AJAX libraries and frameworks. If you choose to write your own AJAX clients-side script you are much better off not re-inventing the wheel.

AJAX in Action by Dave Crane and Eric Pascarello with Darren James is good resource. This book is helpful for the Java developer in that in contains an appendix for learning JavaScript for the Java developer.

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the OPPOSITE is true.

Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass ICON, waiting around for the server to do something.

The synchronous interaction pattern of a traditional web application (top) compared with the asynchronous pattern of an Ajax application (bottom).

Every user action that normally would GENERATE an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server such as simple DATA validation, EDITING data in memory, and even some navigation the engine handles on its own. If the engine needs something from the server in order to respond if it’s submitting data for processing, loading additional interface code, or retrieving new data the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.

Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.

The synchronous interaction pattern of a traditional web application (top) compared with the asynchronous pattern of an Ajax application (bottom).

Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server such as simple data validation, editing data in memory, and even some navigation the engine handles on its own. If the engine needs something from the server in order to respond if it’s submitting data for processing, loading additional interface code, or retrieving new data the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.

Google is making a huge investment in developing the Ajax approach. All of the major products Google has introduced over the last year like Orkut, Gmail, the latest beta VERSION of Google Groups, Google Suggest, and Google Maps are Ajax applications. (For more on the technical nuts and BOLTS of these Ajax implementations, check out these excellent analyses of Gmail, Google Suggest, and Google Maps.) Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon’s A9.com search engine applies similar TECHNIQUES.

These projects demonstrate that Ajax is not only technically sound, but also practical for real-world applications. This isn’t another technology that only works in a LABORATORY. Ajax applications can be any size, from the very simple, single-function Google Suggest to the very complex and sophisticated Google Maps.

At Adaptive Path, we’ve been doing our own work with Ajax over the last several months, and we’re realizing we’ve only scratched the surface of the rich interaction and responsiveness that Ajax applications can provide. Ajax is an IMPORTANT development for Web applications, and its importance is growing. The biggest challenges in creating Ajax applications are not technical. The core Ajax technologies are mature, stable, and well understood. As there are so many developers out there who already know how to use these technologies, we expect to see many more organizations following Google’s lead in reaping the competitive advantage Ajax provides.

The challenges are for the designers of these applications to forget what we think we know about the limitations of the Web, and begin to imagine a wider, richer range of possibilities

Google is making a huge investment in developing the Ajax approach. All of the major products Google has introduced over the last year like Orkut, Gmail, the latest beta version of Google Groups, Google Suggest, and Google Maps are Ajax applications. (For more on the technical nuts and bolts of these Ajax implementations, check out these excellent analyses of Gmail, Google Suggest, and Google Maps.) Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon’s A9.com search engine applies similar techniques.

These projects demonstrate that Ajax is not only technically sound, but also practical for real-world applications. This isn’t another technology that only works in a laboratory. Ajax applications can be any size, from the very simple, single-function Google Suggest to the very complex and sophisticated Google Maps.

At Adaptive Path, we’ve been doing our own work with Ajax over the last several months, and we’re realizing we’ve only scratched the surface of the rich interaction and responsiveness that Ajax applications can provide. Ajax is an important development for Web applications, and its importance is growing. The biggest challenges in creating Ajax applications are not technical. The core Ajax technologies are mature, stable, and well understood. As there are so many developers out there who already know how to use these technologies, we expect to see many more organizations following Google’s lead in reaping the competitive advantage Ajax provides.

The challenges are for the designers of these applications to forget what we think we know about the limitations of the Web, and begin to imagine a wider, richer range of possibilities

AJAX (Asynchronous JavaScript and XML) is a newly coined term for two powerful browser FEATURES that have been around for years, but were overlooked by many WEB developers until recently when applications such as Gmail, Google Suggest, and Google Maps hit the streets.

Ajax isn’t a technology. It’s really several technologies, each FLOURISHING in its own right, coming together in powerful new ways. Ajax incorporates:
* standards-based PRESENTATION using XHTML and CSS;
* dynamic display and interaction using the Document Object Model;
* data interchange and manipulation using XML and XSLT;
* Asynchronous data retrieval using XMLHttpRequest;
* JavaScript binding everything together.

AJAX (Asynchronous JavaScript and XML) is a newly coined term for two powerful browser features that have been around for years, but were overlooked by many web developers until recently when applications such as Gmail, Google Suggest, and Google Maps hit the streets.

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:
* standards-based presentation using XHTML and CSS;
* dynamic display and interaction using the Document Object Model;
* data interchange and manipulation using XML and XSLT;
* Asynchronous data retrieval using XMLHttpRequest;
* JavaScript binding everything together.