ASP. NET component design step by step (6)

ASP. NET component design step by step (6)

Ing back events to server events

If a POST request is sent to the server on the Asp.net page, the framework generates and calls controls according to the event cycle, and controls (if callback is supported) load and return data, the server-side events mapped to the control are like replay of the customer's behavior (the client presses a button, but triggers the Click Event of the server-side control ). What is the mechanism?

If a control needs to handle the return event, a specific interface ipostbackeventhandler must be implemented:

Public interface ipostbackeventhandler {

Void raisepostbackevent (string eventargument );

}

And another interface:

Ipostbackdatahandler

{

Bool loadpostdata (string postdatakey, namevaluecollection postcollection );

Void raisepostdatachangedevent ();

}

Once these interfaces are implemented by the control, the page framework automatically calls ipostbackdatahandler of the control after the PostBack data is completed. Loadpostdata allows the control to read post data. Postdatakey is the name key of the PostBack data. You can use namevaluecollection [postdatakey] to obtain the value passed to the control by the page framework. The control should read this value and update its internal status to reflect status changes. If the control returns true, the status of the server control changes. The page framework immediately calls the raisepostdatachangedevent method of the control. In this case, the control should define the events that cause the server control to provide externally. These events are often the stage of code carefully designed by the control programmer for the aspx programmer who uses the control key.

Another API, ipostbackeventhandler, is also the API called by the server during callback. We know that each control has a uniqueid. When the client triggers a client event that can cause a return (such as pressing the submit button), the http post data is naturally sent to the server, when the Server Page framework performs PostBack processing, it will retrieve whether the control supports the ipostbackeventhandler interface, and immediately call the raisepostbackevent method of this interface when finding the uniqueid of the control, the uniqueid control has an event to be captured. Obviously, not all events on the client can be projected to the server, but only events and controls that can trigger post back (events that can submit form data to the server. Note that the uniqueid must be consistent with the client on the server side. Otherwise, the event cannot be mapped.

It is worth noting that if you want to implement an interface, you need to implement the following interface, instead of simply having the same name as the interface method:

Void ipostbackeventhandler. raisepostbackevent (string eventargument)

{

......

}

That is to say, the interface is implemented by the page framework.

On the other hand, on the client side, there are actually only two HTML elements <inoput type = submit> and <input type = image, but through the client script, other client events can also cause data to be returned to the server. The page class provides a series of methods to help implement other methods that can trigger callback:

 

Public String getpostbackclientevent (

Control,

String argument

);

Obtain the reference to the client script function. When called, this function will cause the server to send back to the form.

 

Public String getpostbackclienthyperlink (

Control,

String argument

); Append javascript: to the beginning of the response returned by the getpostbackeventreference call, so that the server can perform hyperlink sending back.

 

Public String getpostbackeventreference (control );

Public String getpostbackeventreference (control, string );

Obtain the reference to the client-side script function.

 

If a control determines that a return event is triggered by the client through the above method, the Control Reference page will result in the final output to the client's HTML containing the script, and the script contains the following hidden variables:

<Input type = "hidden" name = "_ eventtarget" value = ">

<Input type = "hidden" name = "_ eventargument" value = ">

<Script language = "JavaScript">

<! -

Function _ dopostback (eventtarget, eventargument)

{

VaR theform = Document. _ CT10;

Theform. _ eventtarget. value = eventtarget;

Theform. _ eventargument. value = eventargument;

}

-->

</SCRIPT>

Any client script can be uploaded back to the server only after the _ dopostback method is legally called, and the server knows that the event of the uniqueid control is triggered.