As is pointed out, there are a lot of puzzles and awkwardness to tackle in dealing with the XML typed data using a Microsoft AJAX client-centric scheme. Therefore, here, we still have to resort to the original AJAX mode when adding posts (which will be persisted in the '.xml' file form) to the present article.

Now, when you click the Reply hyperlink at the ContentList.aspx page, you will be redirected to another page named ReplyMsg.aspx. The following Figure 13 corresponds to it as a design-time snapshot.

Figure 13-the design-time snapshot when replying to the current article.

Whether the inner logic or the user interface design, this part is quite similar to the above 'Writing a New Article Using......'. Therefore, we will make a long story short. The above Reply hyperlink corresponds to the following HTML code:

<div >

<a id='btnReply' href="javascript:backdata()" title="Reply the
post">

<img src="images/reply.PNG" />

</a>

</div>

Obviously, all the secrets are wrapped in the JavaScript function backdata:

function backdata(){

  document.getElementById("hintMsg").innerHTML="Posting Data...";

   var filename=getParm();

   var title=document.getElementById("txttitle").value;

   var content=document.getElementById("txtcontent").value;

 createHTTP();

  xmlhttp.onreadystatechange=stateChange;

  xmlhttp.open("POST","ReplyMsgServer.aspx?filename="+
filename+"&title="+escape(title)+"&content="+escape
(content),true);

  xmlhttp.send(null);

}

As is seen from above, all the coding here exactly resembles the coding we did for posting a new article.

Next, let's take a look at the server side programming within the  'ReplyMsgServer.aspx.cs' file (the so-called 'CGI'). As usual, we first give the related code snippet, as follows:

protected void Page_Load(object sender, EventArgs e){

  ArticleManager manager = new ArticleManager();

   string filename = Server.MapPath(".") + @"" +
Request.QueryString["filename"] + "file.xml";

  manager.UpdateXmlFile(filename, Request.QueryString["title"],

Request.QueryString["content"],
HttpContext.Current.User.Identity.Name);

manager.UpdateDatabase(int.Parse(Request.QueryString
["filename"]));

  Response.Write("");

}

There are still four tasks to perform:

1. Accept the passed parameters and rebuild a file name with full path. 
   
2. Update the corresponding '.xml' file that holds the detailed article content. 
   
3. Update the general article information into the database table. 
   
4. Post back to the client side the message about the asynchronous invocation. All the contents relevant to the UpdateXmlFile() and UpdateDatabase() functions are nearly the same as those in the above AddXML() and AddArticle() functions.

Here, still for the sake of brevity, we omit all of them. However, there turns up a peculiar bug here that I have to mention. If we, as usual, replace the above last sentence with the following:

Response.Write("The asynchronous invocation is successful!");

I will see some messy content (beginning with this above specified hint message) at the bottom of the above Figure 13. To my astonishment, anything else is still OK-we can , as usual, see the recently-posted contents when we again launch the web application! For this reason, I have to post an empty string to the client side. If anyone e is successful in overcoming this bug, I would be very glad to hear about it. 

Oh, so much is for this long and mildly awkward application. You can finally press F5 and give it a test!