How server events are triggered in .NET.

Question

I am new to .NET, I have some doubts in my mind. Can someone help me figure it out?

• When a user requests a file (*. ASPX), the request is first sent to the IIS server, and with the help of handlers and modules it finds the type of file that needs to be processed and sent back to the client. But when displayed on a cilent machine, the contents of the .ASPX file will be displayed as HTML controls. How are events generated on the client side and sent back to the server?

• I know that runat = server reports that the control will be processed on the servers. But every time, why do we need to write "runat = server". Is there any ASP.NET control that runs on the client side?

Answer 1

if you start with .NET web development, ASP.NET MVC is the IMO path

the ASP.NET server control that creates client events in the browser implements standard dom events through javascript code that is entered on the page sent from the web server. try viewing the source of the page from any browser to see what is actually created, and the image will become more understandable.

Essentially, runat = server tells the ASP.NET parser to process the tag and generate some special HTML output for this page. see the GvS explanation in this thread on how client events for these controls are converted to a POST form that is processed on the server.

http://www.w3schools.com/aspnet/aspnet_intro.asp

How does ASP.NET work?

When the browser requests the HTML file, the server returns the file. When the browser requests the ASP.NET file, IIS sends the request to the ASP.NET engine on the server. The ASP.NET engine reads the file line by line and executes scripts in the file. Finally, the ASP.NET file is returned to the browser as plain HTML

also see

http://www.w3schools.com/aspnet/aspnet_controls.asp

http://www.w3schools.com/aspnet/aspnet_events.asp

Answer 2

HTTP request / response loop

HTTP is a stateless protocol . - Another aspect of web development that is noticeably different from traditional desktop programming is the fact that HTTP is essentially a conductor without attacks. As soon as the web server sends a response to the client browser, everything about the previous interaction is forgotten. This, of course, does not have a place in a traditional desktop application, where the state of the executable file is most often live and kicked until the user turns off the main application window.

How does Asp.net work?

• View state : the actual mechanism for maintaining state upon request (known as view state) is done by adding hidden fields for different controls in visualized HTML, which is then sent back and forth to the server / client.
• Page life cycle : the mechanism for connecting events on the client side from the server side, the code of the event handler, part of the page life cycle, can be extremely complex and delicate. Few developers successfully manage the management hierarchy in runtime without receiving a State State State State error, or discovering that some event handlers are mysteriously not executing.
• A false sense of separation of concerns : the code-based ASP.NET code model provides means that the application code is derived from its HTML markup and into a separate code class. This was widely welcomed to separate logic and presentation, but in fact, developers are encouraged to mix presentation code (for example, manipulating the control tree on the server side) with their logic application (for example, manipulating database data) in these same monstrous code classes. The end result may be fragile and incomprehensible.
• Limited control over HTML : server controls display themselves as HTML, but not necessarily the HTML you want. Prior to ASP.NET 4, HTML output generally did not comply with web standards or did not use cascading style sheets (CSS), and server controls generate unpredictable and complex identifier values ​​that are difficult to access using JavaScript. These issues are reduced in ASP.NET 4, but it can still be tricky to get the expected HTML.

ESSENCE

What actually happens is that when the request is received in IIS for the .aspx file, Asp.net first displays the corresponding hidden-state HTML for the various controls on the page. This HTML code is then sent to the client. If the user sends messages back, then the values ​​are retrieved from these hidden fields and used.

Answer 3

When you point the tag to runat="server" , you will inform the server of the tag registration. Now the tag is included in the control / tag tree on the server and can be found on the server: when an event is triggered or when attributes or content are changed on the server side.

Events on the client side are silently converted to the POST form. Together with additional information, such as the identifier of the control and the type of event.

Since your tag is registered on the server, it has an identifier that is also passed to the client (look at the html source). This tree is created (by parsing the .aspx file) before the event is fired. Using this identifier, you can find the tag in the control tree / tag on the server side and run the method that is used to process the event.

Using this technique and a lot of ViewState, Asp.Net tries to deny the nature of HTTP without attack. At first it looks like a good idea, IMHO, it is better not to fight with nature. Currently, ASP.Net MVC feels more natural.

Answer 4

This event, which has just appeared on the server controllers, when you click the asp button, the event information and the event message sent to the server via the HTTP post recorded on the client. I believe that this is possible using some registered event on the server. When you load a page, some events recorded in your page structure and raised by the http post request.

See that one of the differences between the client and server controls is the server side registered on the server, and you can save your state in the view state, for example. when you click the button on the server side, its client event and server side first occur. Note that since the server side controls the event registered on the server, when you click on the button, you publish the page back. But the client side controls are just valid in the client, and their event just raised a web browser for you

need more help? comment me to edit my answer respect, Ali