ASP.NET

Designed to emulate the control-based interface of a Windows application
1. Two problems
  1. Web applications execute on the server
    1. Events occur on the client
    2. Events are processed on the server
    3. Solutions
      1. Postback
      2. Automatic Postback
      3. Posting back without hitting the submit button
      4. Example
      5. Changing a selection in a list
      6. Clicking a checkbox
      7. How it works
      8. set AutoPostBack property to true
      9. a JavaScript function is added called _doPostBack() which triggers the posting of the form
      10. the control's onclick, onchange, etc property is set to this function
      11. two hidden input fields which convey
      12. ID of the control that raised the event
      13. any additional information
      14. doPostBack() sets the value of these fields before posting the form
      15. Any additional controls using AutoPostBack are tied in to the doPostBack() function
      16. doPostBack() is the intermediary between the client and the server
  2. Web applications are stateless
    1. Before the rendered HTML is sent back all objects and client-specific information is trashed
    2. Solutions
      1. View State
      2. When page is posted back
      3. ASP.NET re-creates the page and control objects to their default state (using aspx)
      4. viewstate information is deserialized and used to update all the controls
      5. The page is now in the state it was in right before being sent to the client the last time
      6. The page is adjusted according to the posted back form data
      7. The page is now in the state it was in as the user last saw it, right before being posted back
      8. the appropriate events are triggered and the code reacts
      9. Upside is Scalability due to server resources being freed after each request
      10. Downsides
      11. Larger page size
      12. takes longer to receive
      13. takes longer to post
      14. Insecure
      15. Client can read the data
      16. Encryption can prevent reading
      17. Client can modify the data
      18. Hash codes can prevent tampering
      19. Viewstate can be disabled per control with EnableViewState=false
      20. How it works
      21. When form data is received, your code may make changes to the page
      22. These changes are not reflected in the form that is posted back
      23. so after the returned form is processed but before it is sent back all the properties on all the controls on the page are examined
      24. If any property is different that default, the data is entered in a hidden field in the <form>
      25. Proxy servers and firewalls may have problems with hidden fields containing too much data
      26. View State Chunking breaks up the view state data among several hidden fields
Running an HTML form
1. 1. user clicks the submit button
2. 2. browser collects the value of each control and pastes it together into a single string
  1. Example
    1. FirstName=Matthew&LastName=MacDonald&CS=on&VB=on
  2. Rules
    1. all data sent occurs in name/value pairs
    2. all name/value pairs are separated with an ampersand
    3. each name/value pair is split with an equal sign
    4. check boxes are left out unless they are checked
3. 3. the string is sent to the page indicated in the form tag using an HTTP POST operation
Running a Web Form
1. 1. read the entire .aspx file
2. 2. generate the corresponding objects
3. 3. fire a series of events
4. These events are responded to through code
Control model
1. a layer of abstraction is placed over the raw form data
  1. original form data is available in Request.Form collection
  2. Request.Form["FirstName"];
  3. This way the values returned are type safe: a checkbox returns a boolean value
2. Advantages
  1. type safe
  2. readable and writable instead of just readable
Event model
1. Process
  1. 1. Page is requested
    1. 2. Page and control objects are created
    2. 3. Initialization code executes
    3. 4. Page is rendered to HTML and returned to the client
    4. 5. Page and control objects are released from memory
  2. 6. A postback is triggered
    1. 7. All form data is submitted back to the server
    2. 8. ASP.NET reads the form data and re-creates the page objects, returning them to the state they were in the last time the page was sent
    3. 9. Appropriate events are triggered (depending on the control that triggered the postback)
    4. 10. The modified page is rendered to HTML and returned to the client.
    5. 11. Page and control objects are released from memory
Web Form Processing Stages
1. 1. Page framework initialization
  1. Page is first created
  2. controls defined with tags in the aspx are generated
  3. view state is de-serialized and applied to the controls
  4. Page.Init event fires
    1. Rarely handled because view state and controls may not exist yet
2. 2. User code initialization
  1. Page.Load event fires
    1. Used to perform required initialization such as filling in dynamic text or configuring controls
    2. IsPostBack has two uses
      1. Since view state is maintained automatically, dynamic data need only be fetched on first page load leading to a performance boost
      2. Change the interface after page's first use
    3. Avoid initializing control properties in Page.Load or set EnableViewState=false because all changes occurring in events are persisted in view state
3. 3. Validation
  1. Validation controls fire
    1. These are rarely responded to
    2. These can be checked using Page.IsValid in another event handler
4. 4. Event Handling
  1. events that have taken place since the last postback are fired
    1. Two types
      1. Immediate response events
      2. Any control that triggered the _doPostBack() function
      3. If AutoPostBack is set to true
      4. If the control was designed to post back (submit button)
      5. Change events
      6. Anything that changed but did not trigger a post back
5. 5. Automatic data binding
6. Cleanup