Top 50 Ajax Interview Questions You Must Prepare 19.Mar.2024

If the data doesn’t change for a particular request URL, HTTP GET requests are necessary. If the state on a server is going to be updated then a HTTP POST is necessary.

ScriptManager is used for handling every ASP.NET Ajax resource and it makes links for the client libraries in ASP.NET Ajax. This me we will be able to use UpdatePanels, PageMethods and others. Also the page request Manager and Application objects are made, they are important in the client life cycle for raising events in the ASP.NET Ajax web pages. It is also good for making proxies for calling web services asynchronously.

Yes but only partially. The majority of browsers give us a built-in XMLHttpRequest JavaScript object but some, like Internet Explorer, will asked it in the form of an ActiveX object.

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.

Not really, because the code that has to run on the client is complicated and it is hard to create such a code, without having bugs and we need the aid of many tools of an efficient code.

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".

  response.setContentType("text/xml");
response.getWriter().write("<response>invalid</response>");

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.

  response.setContentType("text/xml");
response.setHeader("Cache-Control", "no-cache");
response.getWriter().write("<response>invalid</response>");

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 appearance of a page is changed very much when we used Ajax interaction to dynamically update it. Because of the dynamically changes, also the state of the page is modify and the page behavior has to be defined for the following actions :navigation, using back , slash forward, page bookmarks, URL sharing, time dependant , printing of pages.

  • Navigation-we have to define page refreshing, back and forward and so on .For simplifying navigation we can use a Java Script framework like Dojo.
  • For bookmarking or URL sharing we have Dojo.
  • Printing-problems may appear when the rendered pages are printed dynamically.

From your JavaScript clients you can access data in other domains if the return data is provide in JSON format. In essence you can create a JavaScript client that runs operates using data from a different server. This technique is know as JSON with Padding or JSONP. There are questions as to whether this method is secure as you are retrieving data from outside your domain and allowing it to be excuted in the context of your domain. Not all data from third parties is accessible as JSON and in some cases you may want an extra level of protection. With Java you can provide a proxy to third party services using a web component such as a servlet. This proxy can manage the communication with a third party service and provide the data to your clients in a format of your choosing. You can also cache data at your proxy and reduce trips to service. For more on using a Java proxy to create mashups see The XmlHttpProxy Client for Java.

XMLHttpRequest, this protocol is meant for doing requests to a server. The client browser makes an object, the trfer of data happens in JSON or plain text. The JSON format can be parsed by java script and will be compatible with every browser.

Because XMLHttpRequest is just a piece of Ajax, the wer will be no. Ajax depends on many pieces like XMLHttpRequest, CSS, DOM, etc. XMLHttpRequest is the part responsible for asynchronous server communication.

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.

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.

The wer to all of these questions is “maybe”. Many developers are already working on ways to address these concerns. We think there’s more work to be done to determine all the limitations of Ajax, and we expect the Ajax development community to uncover more issues like these along the way.

HTML_AJAX doesn't have specific pl to integrate with other JavaScript libraries. Part of this is because external dependencies make for a more complicated installation process. It might make sense to offer some optional dependencies on a library like scriptaculous automatically using its visual effects for the loading box or something, but there isn't a lot to gain from making default visuals like that flashier since they are designed to be asily replaceable.

Most integration would take place in higher level components. Its unclear whether higher level components like that should be part of HTML_AJAX delivered through PEAR or if they should just be supported by HTML_AJAX and made available from http://htmlajax.org or some other site. If your interested in building widgets or components based on HTML_AJAX please let me know.

HTML_AJAX does however offer the ability to use its library loading mechanism with any JavaScript library. I use scriptaculous in conjunction with HTML_AJAX and I load both libraries through the server.

To do this you just need to register the library with your server and load add its flag to your include line.

  <?php
$this->server->registerJSLibrary('scriptaculous',
array('prototype.js','scriptaculous.js','builder.js','
effects.js','dragdrop.js','controls.js','slider.js'), '/pathto/scriptaculous/'); 
?>
<script type="text/javascrpt" src="server.php?client=scriptaculous"> </script>

No. Or not yet. It is part of the DOM Level 3 Load and Save Specification proposal.

Internet Explorer 5.0 and up, Opera 7.6 and up, Netscape 7.1 and up, Firefox 1.0 and up, Safari 1.2 and up, among others.

AJAX is a browser-dependent technology. The Ajax engine runs on Firefox, Opera 8, Safari and later Mozilla builds, and the Microsoft ActiveX object.

XAJAX uses XML as a trport for data between the webpage and server, and you don't write your own javascript data handlers to manipulate the data received from the server. Instead you use a php class and built in javascript methods, a combination that works very similiar to the HTML_AJAX_Action class and haSerializer combo. XAJAX is designed for simplicity and ease of use.

HTML_AJAX allows for multiple trmission types for your ajax data - such as urlencoding, json, phpserialized, plain text, with others planned, and has a system you can use to write your own serializers to meet your specific needs. HTML_AJAX has a class to help generate javascript (HTML_AJAX_Helper) similiar to ruby on rail's javascript helper (although it isn't complete), and an action system similiar to XAJAX's "action pump" that allows you to avoid writing javascript data handlers if you desire.

But it also has the ability to write your own data handling routines, automatically register classes and methods using a server "proxy" script, do different types of callbacks including grabbing remote urls, choose between sync and async requests, has iframe xmlhttprequest emulation fallback capabilities for users with old browsers or disabled activeX, and is in active development with more features planned (see the Road Map for details)

HTML_AJAX has additional features such as client pooling and priority queues for more advanced users, and even a javascript utility class. Although you can use HTML_AJAX the same way you use XAJAX, the additional features make it more robust, extensible and flexible. And it is a pear package, you can use the pear installer to both install and keep it up to date.

If you're asking which is "better" - as with most php scripts it's a matter of taste and need. Do you need a quick, simple ajax solution? Or do you want something that's flexible, extensible, and looking to incorporate even more great features? It depends on the project, you as a writer, and your future pl.

The technologies that represent Ajax belong to the client and they make possible an asynchronous client to server communication. When synchronous communication is involved at every event a complete round trip takes place, issue solved by using asynchronous communication.

Load Runner supports AJAX Apps. However, Ajax protocols in Load Runner are not as efficient as they are in HTTP. Yet, using HTTP to record AJAX web requires copious custom coding. AJAX protocols heavily depend on memory, and running more than 2GB of ram could cause the machine to freeze.

Not at all. Macromedia is an Adaptive Path client, and we’ve long been supporters of Flash technology. As Ajax matures, we expect that sometimes Ajax will be the better solution to a particular problem, and sometimes Flash will be the better solution. We’re also interested in exploring ways the technologies can be mixed (as in the case of Flickr, which uses both).

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

Sometimes yes, sometimes no. It can be more like a server-side centralized component or controller or client-side controller. A centralized server-side controller is the case where we must assure that the client-side page data is synchronized with the server data. Many programs are preserving everything on the server and the updates are given to the client DOM through an easy Java Script controller. The case of client and server-side controllers uses a JavaScript for making each control that relates to presentation, each processing of events, each manipulation of pages and model data rendering on the client. The responsibility of business logic or giving the updated model data to a client is taken by the server-side. But this case doesn’t include specific information about the initial pages which is sent to the request of the client page. In certain use cases the whole Ajax application is possible to write in one page. If we chose this we must also remember about bookmarking and navigation.

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.

No. XML is the most fully-developed me 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 me of structuring data for interchange.

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.

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.

We don’t know yet. Because this is a relatively new approach, our understanding of where Ajax can best be applied is still in its infancy. Sometimes the traditional web application model is the most appropriate solution to a problem.

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.

For managing concurrent request we can write a function or we can use Java Script closures. After code processing is finishes the call back function and the URL would pass as parameters, they are passed to the object (Ajax Interaction). These closures are good in the way that they insure the right callback function will be invoked and this will have a particular Ajax Interaction.

Depending upon the browser...

  if (window.ActiveXObject)   {   // Internet Explorer http_request = new  ActiveXObject("Microsoft.XMLHTTP");   }  else if.

During the initiation of synchronous requests, the script desists and awaits a reply from the server before proceeding; but during the initiation of asynchronous requests, the script sanctions the procession of the page and handles the reply.

Many amazing things can be done with AJAX/DHTML, but there are limitations. AJAX and applets can be used together in the same UIs, with AJAX providing the basic structure and applets providing more advanced functionality. The java applet can communicate to JavaScript using the Live-Connect APIs. One should not ask: “should we use AJAX or applets?” Instead, one should discover which technology best fits your needs. In summary, AJAX and applets need not be mutually exclusive.

Current AJAX applications use polling to communicate changes data between the server and client. Some applications, such as chat applications, stock tickers, or score boards require more immediate notifications of updates to the client. Comet is an event based low latency server side push for AJAX applications. Comet communication keeps one of the two connections available to the browser open to continuously communicate events from the server to the client. A Java based solution for Comet is being developed for Glassfish on top of the Grizzly HTTP connector. See Enabling Grizzly by Jean-Francois Arcand for more details.

Some applications and scenarios in which AJAX is utilized include login forms, auto-complete (e,g. Google search ), voting and rating systems, updating with user content, form submission and validation, chat rooms and instant messaging, Slicker UIs, external widgets, light-boxes (as opposed to pop-ups), and Flash (e.g. Flash games).

JavaScript is a language, while j-query is merely a library written using JavaScript. This library is light-weight, cross-browser compatible, and simple. One can also assert that j-query is a plugin used to build function.

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.

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.

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

  <form onSubmit="doAJAXSubmit();return false;" >
<input type="text" id="tf1" />
<input type="submit" id="submit1" value="Update"/>
</>

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

  <form onSubmit="doAJAXSubmit();return false;" >
<input type="text" id="tf1" />
<input type="button" id="button1" onClick="doAJAXSubmit()" value="Update"/>
</>

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.

Ajax is a form of JavaScript, which uses XML Http Request objects that take action event parameters into a method called “open”. The term AJAX symbolizes Asynchronous Java script and XML, wherein there is no order in which the requests and responses are tracked.”XMLHttpRequest.open” takes action events as URL Parameters. On the other hand, “XMLHttp Request.send” sends the Request object either asynchronously or synchronously, depending on whether the option for the synchronous version is true or false.

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.

Just call the abort() method on the request.

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 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 only to enhance the user experience of our applications.

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.)

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

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.

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.

The Animation Extender control permits you to program fluid animations to the controls that you put on the page. This control allows you to program elements that can move around the page based upon specific end user triggers (such as a button click). There are specific events available against which to program your animations. These events include “OnClick,” “OnHoverOver”, “OnHoverOut”, “OnLoad,” “OnMouseOver,” and
“OnMouseOut,” which are to be constructed as:
<ajaxtoolkit:AnimationExtender id=”ani” targetcontrolid=”anipanel” runat=”Server”>
<asp:panel id—“anipanel” runat=”server”>
</ajaxtoolkit:AnimationExtender>