In the Basic ASP. under the net ajax framework, we have three methods to perform Control-based Ajax operations: UpdatePanel, ICallbackEventHandler, and IScriptControl. Let's take a look at their features and scenarios.
UpdatePanel
UpdatePanel is the easiest way to interact with the server logic. It cannot even be called interaction-you don't need to touch any client logic at all. A server-side operation, after being "hijacked" by UpdatePanel, becomes a client operation, which directly calls the corresponding server-side operation.
If you use UpdatePanel to make a selection dialog box with branches, how should we design it? Do not go to the confirm method of the client. It is too difficult, or it is too non-ASP. net ajax. With UpdatePanel, we should stick to its philosophy that all client operations are phantom, and all operations are actually performed on the server side, including the selection dialog box. To follow the ASP. NET idea, I will make a selection dialog box control. Its essence may be a floating layer simulation dialog box, which is implementation details and we don't need to pay too much attention to it. The point is that the branch logic of this selection dialog box is completely performed on the server side. After Async PostBack, the server side determines how to trigger the event based on the data submitted. In this way, the entire branch selection logic is embedded in the Page processing process, without the need to use Cookies or sessions for data transfer media, this avoids the tight coupling between the Page processing process and data in a larger scope.
UpdatePanel is applicable to the Development of logic on the server side. I recommend that you put all logic on the server side when using UpdatePanel. Do not write some code for mixed server logic and client logic. Some people will say that you think Lao Zhao is very fond of moving that Sys. net. webRequestExecutor is used to change the UpdatePanel behavior, but it is actually part of the hierarchical design idea. It is the logic in a hierarchy that changes that thing, as long as the interfaces between layers remain unchanged, the specific implementation can be designed as needed. However, if you use UpdatePanel and use Cookies or sessions to transmit values, this will span n layers and increase coupling.
ICallbackEventHandler
I have already said ICallbackEventHandler for countless times. The point is that you must use the Page processing process to think about it. As long as you understand the Page processing process, you will understand why ICallbackEventHandler is in. NET Framework 2.0 Beta2 has only one method, and RTM has to be split into two methods. For more information, see ASP. NET 2.0 ClientScript Callback.
What should I do if I use ICallbackEventHandler to implement a selection dialog box with branches? Similar to using UpdatePanel, I will make a selection dialog box control that inherits from ICallbackEventHandler. When writing JavaScript For this control and implementing the ICallbackEventHandler interface, I will ensure that JavaScript gives the correct call parameters to Callback, receive these parameters in the implementation of the interface method, and then trigger the correct event, that's simple. Like UpdatePanel, do not deviate from the design philosophy of ICallbackEventHandler. Its processing flow must be merged into the Page processing flow, and your control must be designed like this.
When should I select ICallbackEventHandler? If you have a lightweight Ajax operation, but it is costly to update the HTML of the entire region using UpdatePanel, you can consider using ICallbackEventHandler. Of course, the premise is that you understand control development and JavaScript.
IScriptControl
This is the most complicated solution. You need to implement two copies of a Control-one server and one client. Some logic is implemented twice on the client and server, while the other logic only needs to be implemented once on the client or server. The typical IScriptControl example is the Timer control that comes with ASP. net ajax. Its timer is purely client logic, but the Tick event is triggered on the server, and Async PostBack becomes a bridge between the two. Of course, in terms of Control itself, it does not care whether PostBack is asynchronous or not. The Tick event is triggered only by PostBack.
If IScriptControl is used to implement the selection dialog box with branches, it will be very similar to the version of ICallbackEventHandler. The only difference is that its logic on the client will be encapsulated into a Sys. UI. control, while the client logic of ICallbackEventHandler is usually not encapsulated. This advantage is obvious, that is, the code is easier to maintain, and the Control of the client can also be added to event support, and provide the same code branch events as the server side. You need to know the Timer control in the CTP stage. Its Client Version is Sys. sys. UI. _ Timer) is a tick event that corresponds to the Tick event on the server, but RTM cancels this function because ASP. net ajax 1.0 focuses entirely on server-side functions, and all client functions are cut down.
Under what circumstances should I choose IScriptControl? If you think your client logic should be encapsulated as a derived class of Sys. UI. Control, choose IScriptControl.
Summary
We have discussed three methods of Ajax calling through Control, and repeatedly stressed that the design must be based on the Page processing process. Do not add unnecessary complexity and coupling between the process. It is worth mentioning that there are many people who question why such a branch selection dialog box function should be provided on the Web. My opinion is as follows: since the process of the client software has this function, it is quite normal for the Web application to have this function. When you delete a blog post, ask if you are sure to delete it, do some people think this function is a design error? What may be different is just the form, whether it is a confirm or a pop-up layer, or even a dedicated transition page. However, from the perspective of user experience, this is actually not the best solution. Most of the time you delete a user, you confirm the deletion, and you do not need to ask whether to confirm or not, however, developers feel that the consequences of deleting a wrong user's hand should be borne by the user, so they have made such a dialog box to shirk their responsibilities. The real user experience does not need to be confirmed, but the user must be able to recover. It is best to press Ctrl + Z, however, for developers, there are still many operations that cannot be restored. At this time, there is no better solution besides displaying the dialog box.
- Technical details of Microsoft's latest ASP. net mvc Framework Beta edition
- Construct a personalized webpage in ASP. NET
- Advantages and disadvantages of ASP. NET client Status Management