1 / 63

State Management

State Management. Chapter 8. 1. 1. Objectives. You will be able to: Understand the need to retain class member variables across page requests. Use .NET state variables to retain the values of member variables across page requests. View State Session State Application State. 2. 2.

metta
Download Presentation

State Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. State Management Chapter 8 1 1

  2. Objectives You will be able to: • Understand the need to retain class member variables across page requests. • Use .NET state variables to retain the values of member variables across page requests. • View State • Session State • Application State 2 2

  3. Repeat the Hello Page • Dowload Hello_CSS.zip from the class web site: • http://www.cse.usf.edu/~turnerr/Web_Application_Design/Downloads • Expand .zip file. • In Visual Studio 2010, • File > Open > Web Site • Navigate to expanded folder and Open 3 3

  4. View Solution Explorer Be sure you have the right files. 4

  5. Add this. The Code-Behind File 5 5

  6. Run the App Enter name and then click OK. 6 6

  7. After Clicking OK The textbox is still filled. 7 7

  8. The TextBox is Still Filled • We didn’t set the Text property of the TextBox. • The server received the user input. • Set the Text in the TextBox when it sent the HTML for this page down to the browser in response to the postback. • Restored the appearance of the page as it was before the postback. 8

  9. The TextBox is Still Filled This doesn’t happen with an HTML page. The textbox is empty when a fresh copy of the page is loaded on postback. 9 9

  10. Add a Cancel Button Set ID and Text properties. Double click on Cancel button to add event handler. 10 10

  11. Let Cancel Clear the TextBox 11 11

  12. Try it! • Fill in name. • Then click Cancel rather than OK 12 12

  13. After Cancel Clicked Now the TextBox is clear. 13

  14. Try it again! • Fill in name. • This time click OK, then click Cancel. 14

  15. After Cancel The TextBox is clear, but the greeting is still there! 15 15

  16. The Greeting Was Restored • The greeting was restored by the server before the HTML was sent down to the browser. • But the greeting is not an input. • How did the server know that it should restore the greeting? • How did it know the contents of the greeting? 16 16

  17. Viewstate • The server encoded the appearance properties of the page in a hidden input: • ViewState 17

  18. Look at the Source • Hidden input __viewstate encodes the properties of the page that were set by our code. • Sent back to the server on postback. • If the application code does not change the properties, the previous appearance of the page will be restored when the page is refreshed on the browser. • Including content that was set programatically on an earlier request. 18 18

  19. Clearing the Greeting • If we want a clean copy of the page following Cancel, the event handler for Cancel must reset the greeting. 19 End of Section

  20. Visit Count • Let’s add a counter and keep track of how many times the page has been visited. • New label shows the count. 20 20

  21. Visit Count: Designer 21 21

  22. Visit Count: Code Behind 22 22

  23. After First OK 23 23

  24. After Second OK 24 24

  25. What’s going on here? • Why is count still 1 after additional OK clicks? • Each OK sends a fresh copy of the page to the browser. • count is reinitialized each time. • To persist member variables across page loads, we can use session variables. • Each user session will have its own copy. 25 25

  26. Using a Session Variable Note C# indexer syntax. 26 26

  27. Session State • The Session object is a collection of name-value pairs. • We can read and write a value using its name as an indexer. • Values are stored as objects. • We have to typecast them on retrieval. • Session is normally stored in server memory. • Persists as long as the session lives. 27

  28. Initial Page 28

  29. After First OK 29

  30. After Second OK 30 30

  31. Very Important • Any member variable that we want to remember from one page request to the next should be preserved in a session variable. • Alternative to hidden inputs • Create session variables for member variables that need to be preserved across interactions. • Get values on Page_Load • Check for existance and create if necessary. • Update values when they change. 31 31

  32. Session Variables • Each session gets its own copy of all session variables. • But what is a session? • Look at the web site on a server, from various browsers and browser windows. 32

  33. First Browser 33

  34. First Browser After a few clicks on OK. 34

  35. Another Tab on Same Browser Same session. 35

  36. Same Browser, Another Window Same session. 36

  37. Different Browser New session. 37

  38. New Window at Later Time New browser instance gets existing session. (After some amount of time the session will expire.) 38

  39. From a Different Computer • Browsers on different computers always have separate sessions. 39

  40. Conclusions • Be cautions about multiple tabs and multiple browser windows. • Different tabs of a browser get a single session. • Same browser in separate windows of the same computer get a single session. • Different browsers on the same computer get different sessions. • Browsers on different computers have separate sessions. 40

  41. Using ViewState • SessionState is stored in the server. • Rather than using SessionState we can use ViewState to persist class variables. • Values are stored in the __VIEWSTATE hidden variable sent to the browser and returned on PostBack. • Each window and each tab will have a separate copy of ViewState. 41

  42. Using ViewState 42

  43. Looks the Same 43

  44. After First OK 44

  45. New Tab 45 Gets own copy of the count.

  46. ViewState • A variable stored in ViewState is reinitialized on each direct request for the page (vs. PostBack). • Old values are restored only on postback. 46

  47. Try it! 47

  48. SessionState vs. ViewState • Each has advantages and disadvantages. • SessionState • Stored on the server. • Relatively safe from hacking. • Is shared across tabs and windows • Persists for some time after browser window is closes. • Is not reinitialized on a direct request for the page. • Is shared among different pages of an app. 48

  49. SessionState vs. ViewState • Each has advantages and disadvantages. • ViewState • Is included in the page sent to the browser. • Easily hacked. • More communication overhead. • Less server overhead. • Not shared across tabs and windows. • Is not shared among different pages • without special effort • Is reinitialized on each direct request for a page. End of Section 49

  50. Application State • Similar to Session State but shared among all sessions running a given app. • Concurrency issues! • Stored in server memory. • Collection created when the application is started. • First request for the URL after server started • Persists so long as the application runs. • Lost when the application is stopped or restarted. • Whenever the server is stopped or restarted 50

More Related