Beginning Ajax with ASP.NET- P12

Beginning Ajax with ASP.NET- P12:Thank you for purchasing Beginning Ajax with ASP.NET. We know that you have a lot of options whenselecting a programming book and are glad that you have chosen ours. We’re sure you will be pleasedwith the relevant content and high quality you have come to expect from the Wrox Press line of books.
Nội dung trích xuất từ tài liệu:
Beginning Ajax with ASP.NET- P12 What Is Built into ASP.NET // Get our callback event reference string js = Page.ClientScript.GetCallbackEventReference(this, “arg”, “OnServerCallComplete”, “ctx”, true); // Create a simplified wrapper method StringBuilder newFunction = new StringBuilder(); newFunction.Append(“function StartAsyncCall(arg, ctx) “); newFunction.Append(“{ “); newFunction.Append(js); newFunction.Append(“ } “); // Now register it Page.ClientScript.RegisterClientScriptBlock(this.GetType(), “NewAsyncMethod”, newFunction.ToString(), true); } #region ICallbackEventHandler Members public string GetCallbackResult() { return “Server method completed at: “ + DateTime.Now.ToLongTimeString(); } public void RaiseCallbackEvent(string eventArgument) { System.Threading.Thread.Sleep(2000); } #endregion } So, now you have a fully functional, albeit very simple, implementation of Asynchronous Client Script Callbacks. The server-side methods in this example are extremely simple and would not normally have any problems or generate any exceptions, but in a normal application where complexity is much higher, this is a very real consideration. Luckily, the asynchronous client script framework provides a mecha- nism for handling this.Handling Errors in the Asynchronous Process When an error occurs on the server, this usually means an exception has been thrown. Obviously, some way of identifying when an exception has occurred and dealing with this on the client browser is required. In the same way that you defined a JavaScript method that is called on completion of the asyn- chronous process, you can define a JavaScript method that is called when an exception is raised on the server during your asynchronous callback. This is specified as an additional parameter in the call to the GetCallbackEventReference method, which is shown in the following example: string js = Page.ClientScript.GetCallbackEventReference(this, “arg”, “OnServerCallComplete”, “ctx”,”OnServerCallError”, true); The parameter that contains OnServerCallError identifies the name of the JavaScript method that is called when an exception occurs on the server. The number of parameters that this method requires is 141Chapter 6 almost identical to the method defined previously to cater for a successful call. The JavaScript imple- mentation for the OnServerCallError method is shown here: function OnServerCallError(err,ctx) { alert(“An error occurred! [“ + err + “] Context passed in was [“ + ctx + “]”); } The first parameter err represents the message of the exception that was generated, and the ctx param- eter represents the same context defined in previous examples. To demonstrate this, the implementations of the server-side methods have been altered to explicitly throw an exception in order to simulate an error condition. In the following example, the GetCallbackResult method has been modified to throw an exception: public string GetCallbackResult() { throw new Exception(“Whoa! This is a server side exception from ‘GetCallbackResult’”); return “Server method completed at: “ + DateTime.Now.ToLongTimeString(); } This time, when the button on the web page is clicked, the asynchronous process is initiated as expected. However, the JavaScript error routine is now invoked, with the exception message being displayed, along with the context data you defined earlier. This, the definition of JavaScript handler methods for both a successful and an unsuccessful call, would typically be basic requirements for any production system using the Asynchronous Client Script Callback techniques. Although the preceding code example allows an exception to be handled by the browser for the purpose of demonstration, it is important that you properly handle all exceptions in your callback code. Normal exception-handling techniques should be used with a try...catch syntax. This way, only exceptions that are meant to be flowed and handled by the browser are allowed by your code. In addition, your server- side code can take action to prevent data corruption or undesired behavior before allowing the exception to be passed up to the client-side code. In the preceding example, the exception was generated from the GetCallbackResult method. The JavaScript error handler method displayed the message of the exception as expected, but what if the excep- tion were generated by the companion RaiseCallbackEvent server-side method? In the following exam- ple, the generation of the exception has been moved to the RaiseCallbackEvent method and removed from the GetCallbackResult method. To aid this example and prevent confusion, the entire server-side code listing is shown: using System; using System.Data; using System.Configuration; using System.Collections; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.WebControls;142 What Is Built into ASP.NET using System.Web.UI.WebControls.WebParts; using System.Web.UI.HtmlControls; using System.Text; public partial class GetCallbackEventWithErrorHandlingExample_GetCallbackEventWithErrorHandlingExample : System.Web.UI.Page, ICallbackEventHandler ...