SitePoint Sponsor |
|
User Tag List
Results 1 to 9 of 9
Thread: View State and ...
-
Mar 13, 2009, 17:23 #1
View State and ...
... the following scenarios.
1) No instances of one control changing anothers through an event (like selecting an option in one select changing the values in another).
2) The above selects would be filled, however, using databinding before display.
Basically, everything that needs filling is done before display, and no content changes due to events.
The question: can I simply turn of viewstate at the page level and let 'er rip? Or will I have to turn off viewstate for each and every control on the page?
-
Mar 14, 2009, 02:01 #2
- Join Date
- Jul 2004
- Location
- Cape Town, South Africa
- Posts
- 2,880
- Mentioned
- 48 Post(s)
- Tagged
- 0 Thread(s)
You can just disable viewstate on the page. No need for each control. But it will not work in ur case. You are going to need viewstate enabled for submitting your form if the page is posting back to itself otherwise the form values will get reset on post back and ur code will grad the default values.
Only way to disable viewstate would be to have the form action set to post to another page.
-
Mar 14, 2009, 09:25 #3
I see, so if a user enters information that is invalid, the only way to re-display the form, using their values, and showing the validator text, viewstate needs to be implemented?
Here's a question then, is it possible to set the values myself after initializing the controls, using values from Page.Form() instead? The reason is that the pages won't be displayed again if successfull. Instead, they redirect one level back. I.E. options/create.aspx will redirect back to options/manager.aspx to display the master list of options.
-
Mar 15, 2009, 03:34 #4
- Join Date
- Jul 2004
- Location
- Cape Town, South Africa
- Posts
- 2,880
- Mentioned
- 48 Post(s)
- Tagged
- 0 Thread(s)
Yes, that is possible. But it is a lot of extra work for what viewstate should do. I disable viewstate site wide and if any page acts strangley.. mainly forms, etc. Then I enable it on that page.
ViewState is not a problem, unless it starts getting really big. So keep viewstate on for forms, etc as it makes life easier... unless it starts effecting performance.
-
Mar 15, 2009, 09:39 #5
- Join Date
- May 2003
- Location
- Washington, DC
- Posts
- 10,653
- Mentioned
- 4 Post(s)
- Tagged
- 0 Thread(s)
Also, check out ASP.NET MVC to leave the world of viewstate behind if you want to go that way.
-
Mar 16, 2009, 15:01 #6
I'm familiar with the pattern having used it in php numerous times. I may indeed play around with it.
-
Mar 22, 2009, 15:00 #7
- Join Date
- Oct 2002
- Location
- Greenock, Scotland
- Posts
- 701
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
You can set the control values before the page load event fires (is page_init) and viewstste will not be tracked. It helps greatly to fully understand the page lifecycle and how viewstate truely works.
-
Mar 28, 2009, 17:27 #8
Just a quick followup question on this. On a relatively simple page, with ViewState on all the runat="server" controls (including <head>) as well as the @Page directive, turned OFF, is it sill normal to see the following in a rendered page? It seems pretty nominal, I just wanted to be sure I wasn't missing a setting somewhere.
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKMTYyNzcxNDY4NmRk" />
-
Mar 30, 2009, 00:35 #9
- Join Date
- Jul 2004
- Location
- Cape Town, South Africa
- Posts
- 2,880
- Mentioned
- 48 Post(s)
- Tagged
- 0 Thread(s)
Yea, that is always on the page regardless if its disabled or not. If its enabled, you will see that variable starting to grow
Bookmarks