I think what you return depends on the situation. If I am going to be returning data that is typically going to be used for display purposes (orders, lists of persons, etc) XML makes sense. But for my typical use of Ajax - changing the content of html select options, I don’t bother returning XML. My servlet that is called does it’s thing (puts what it needs into Request scope) then returns a JSP. The Java Web Parts Ajax tags I use http://javawebparts.sourceforge.net/ make it all very simple. Then in my JSP, I use JSTL to generate the html that I need within JavaScript to replace the divs I need (set element’s innerHTML with my generated javascript).

I see no point in returning XML if I’m just going to be changing stuff like select options or other html form options. You have separation of concerns since you are dealing with display in a totally different area (jsps) (The generated code isn’t being done in the calling servlet).

Can you explain what you mean by changing select options and form options? Do you mean changing the content of them?

Are you saying the part of your application that responds to AJAX requests is returning JSP code that is then executed?

Do you prefer this method because of ease of development, ease of maintenance, processing time (ie. wait time for the user), or another reason?

Brian

Not sure if you can do html quoted text but I’ll try…
[quote]Can you explain what you mean by changing select options and form options? Do you mean changing the content of them?[/quote]

Yes, typically changing the content of them, but sometimes it’s also changing the value of certain text fields and text areas as well. I use the javascript in a JSP approach for cases where I have several items on the page that all need to change based off of one event firing. Imagine you selected an Employee and you needed to populate a bunch of different Employee fields. Stuff like that.

[quote]Are you saying the part of your application that responds to AJAX requests is returning JSP code that is then executed?[/quote]

It’s return a JSP and it’s presumed to be javascript that is contained in it, so that’s actually what is executed. So for example you can do…

document.forms[0].endDateString.value = “${endDateString}”;

or basically anything you would typically do with Javascript to set form values or change options. The difference of course being that you can now use information that was set in a servlet that ajax executed.

If was ‘just’ going to be options in a select list that I needed to change, I could simply return xml in the format

????

and use an approriate renderer that the tag package provides.

Personally I like the javascript approach rendered from a JSP since it’s 1) easy to develop 2) easy to understand 3) easy to maintain. The third being the biggest advantage. Sometimes I’ll get a request that something else must change on the page due to the ajax event, so I basically edit my servlet to make sure I have what I need put into the request, then I just tweak the JSP to make sure the proper javascript is executed.

So basically, that ajax event fires - calls a servlet - some backend processes usually take place to return data. Servlet puts what it needs into request scope. Servlet returns a JSP which has the javascript in it that I want to execute which is usually like…

//build some javascript string, then…
document.getElementById(”theDivSection”).innerHTML = theStringICreated;
//then several others

If you scroll to the bottom section here http://javawebparts.sourceforge.net/javadocs/javawebparts/taglib/ajaxtags/package-summary.html under Standard Request/Response Handlers you can see the different ways you can see the different handlers. There are a lot of standard ones for typical things, but I’ve been finding I like the std:CodeExecuter one the best, since if I often need to do more than one thing based off the ajax event, it’s easy for me to do with javascript. Like in this one stupid app I have, there are bunch of fields and other things that need to change when a single option is selected (it really should be a desktop application and not a webapp imo and hopefully I’ll get to write it as such.)

Thank you for sharing your opinions and methods of using AJAX, Rick. It will make my web site more instructional to have both sides of the debate explained.

I’m also of the persuasion that XML should be returned over straight HTML. Using XML allows you to build a richer response allowing the AJAX code to be a little smarter at handling the returned data.

I like the concept (even if I would have made the implementation a little differently) that Rico has used to always wrap the response in XML, but use attributes in the XML to indicate what it is. For example,


<ajax-response>
<response type="element" id="personInfo">
<div class="person">
<span class="personName">Mr. Pat Barnes</span>
<span class="personAddress">1743 1st Avenue
Boston, Boston 71204-2345</span>
<span class="personOccupation">Executive Vice
President</span>
<span class="personPhoneNumber">Phone #:
(972) 555-0293</span>
<span class="personMobile">Mobile #:
(972) 555-0295</span>
<span class="personNotes">Notes:
Spouse playes tennis at the country club with
John.</span>
</div>
</response>
</ajax-response>


where the type="element" id="personInfo" indicates to Rico to replace the innerHTML of the element with id personInfo with the contents of the response.

On the other hand, in a response like:


<ajax-response>
<response type="object" id="formLetterUpdater">
<person fullName="Pat Barnes" title="Mr." firstName="Pat"
lastName="Barnes" streetAddress="1743 1st Avenue" city="Boston"
state="Boston" zipcode="71204-2345" occupation="Executive Vice
President" phoneNumber="(972) 555-0293" mobileNumber="(972)
555-0295" personNotes="Spouse playes tennis at the country club
with John." />
</response>
</ajax-response>


The type="object" id="formLetterUpdater" calls a JavaScript object registered under the name matching the id of formLetterUpdater. That Javascript would then process the contents of the response as XML to extract whatever data is necessary.

After further consideration I changed my mind. I used a principle of design and architecture that is absolutely correct, but wrongly applied it to the use of AJAX. See my new post on the topic: http://www.brianburridge.com/2006/04/20/ajax-returning-html-change-of-opinion/