|
.net
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
ViewState: why?that: ============ public string Text { get { String s = (String)ViewState["Text"]; return ((s == null) ? String.Empty : s); } set { ViewState["Text"] = value; } } ============ Yet I found that this simpler approach work well ============ string text; public string Text { get { return text; } set { text = value; } } ============ It also doesn't clutter the web page (as the view state is embeded in the page as an input of HIDDEN type). So now I wonder, why use the ViewState exactly? I guess there are reason to do so, like if I want to programatically change the control property with an event handler and keep on further post back. Yet that looks to me as a very marginal exemple. Are there better reason? And how to mark a control in such a way that it won't store its view state in the web page. Such as: I use ViewState to store property (in case they need to be stored), yet I doesn't output this viewstate to the web page, in case it doesn't need to be restored (would be equal to value in the aspx)? Yet that seems quite a marginal All ASP.NET Controls have a property called EnableViewState, you can
disable that if you don't need the viewstate. Remy Blaettler The simpler approach will not retain values between postbacks. So you set
the property, the user clicks a button, and there is another request to the server. At this point, this property no longer has the value you set. This is because HTTP is stateless, and each request to the server means a new page object is created from scratch. The ViewState approach works, because the viewstate is posted back to the server, so the value saved in it can be retrieved. Show quoteHide quote "Lloyd Dupont" <net.galador@ld> wrote in message news:%23VuThc7CGHA.2596@TK2MSFTNGP10.phx.gbl... > When you define UserControl in source code the sample I see are often like > that: > ============ > public string Text > { > get > { > String s = (String)ViewState["Text"]; > return ((s == null) ? String.Empty : s); > } > set > { > ViewState["Text"] = value; > } > } > ============ > Yet I found that this simpler approach work well > ============ > string text; > public string Text > { > get { return text; } > set { text = value; } > } > ============ > It also doesn't clutter the web page (as the view state is embeded in the > page as an input of HIDDEN type). > > So now I wonder, why use the ViewState exactly? > I guess there are reason to do so, like if I want to programatically > change the control property with an event handler and keep on further post > back. > Yet that looks to me as a very marginal exemple. > > Are there better reason? > And how to mark a control in such a way that it won't store its view state > in the web page. > > Such as: I use ViewState to store property (in case they need to be > stored), yet I doesn't output this viewstate to the web page, in case it > doesn't need to be restored (would be equal to value in the aspx)? > Yet that seems quite a marginal > I disagree.
If it's a valid argument for a textbox, a simple label, which value is written in the .aspx, would always have its value set by code / .aspx. A label, for instance, only VERY MARGINALLY need to keep its valu between postabck. (Because its value would most of the time be present in the page trhough code or something, and szeldom come from user event) Show quoteHide quote "Marina" <someone@nospam.com> wrote in message news:uBxtpq7CGHA.336@TK2MSFTNGP14.phx.gbl... > The simpler approach will not retain values between postbacks. So you set > the property, the user clicks a button, and there is another request to > the server. At this point, this property no longer has the value you set. > This is because HTTP is stateless, and each request to the server means a > new page object is created from scratch. > > The ViewState approach works, because the viewstate is posted back to the > server, so the value saved in it can be retrieved. > > "Lloyd Dupont" <net.galador@ld> wrote in message > news:%23VuThc7CGHA.2596@TK2MSFTNGP10.phx.gbl... >> When you define UserControl in source code the sample I see are often >> like that: >> ============ >> public string Text >> { >> get >> { >> String s = (String)ViewState["Text"]; >> return ((s == null) ? String.Empty : s); >> } >> set >> { >> ViewState["Text"] = value; >> } >> } >> ============ >> Yet I found that this simpler approach work well >> ============ >> string text; >> public string Text >> { >> get { return text; } >> set { text = value; } >> } >> ============ >> It also doesn't clutter the web page (as the view state is embeded in the >> page as an input of HIDDEN type). >> >> So now I wonder, why use the ViewState exactly? >> I guess there are reason to do so, like if I want to programatically >> change the control property with an event handler and keep on further >> post back. >> Yet that looks to me as a very marginal exemple. >> >> Are there better reason? >> And how to mark a control in such a way that it won't store its view >> state in the web page. >> >> Such as: I use ViewState to store property (in case they need to be >> stored), yet I doesn't output this viewstate to the web page, in case it >> doesn't need to be restored (would be equal to value in the aspx)? >> Yet that seems quite a marginal >> > > Disagree with what?
Nothing you just said had anything to do with what I was saying at all. Again, defining a property on a page, does not retain the value in that property between postbacks. ViewState is maintained between postbacks, since it is sent down with the page to the browser, and sent up to the server with the post. This is just a fact about how things work. There is nothing here about labels, controls, etc. I'm sorry, but I have no idea what you are talking about. Show quoteHide quote "Lloyd Dupont" <net.galador@ld> wrote in message news:eMPPjFADGHA.1268@TK2MSFTNGP12.phx.gbl... >I disagree. > If it's a valid argument for a textbox, a simple label, which value is > written in the .aspx, would always have its value set by code / .aspx. > A label, for instance, only VERY MARGINALLY need to keep its valu between > postabck. > (Because its value would most of the time be present in the page trhough > code or something, and szeldom come from user event) > > "Marina" <someone@nospam.com> wrote in message > news:uBxtpq7CGHA.336@TK2MSFTNGP14.phx.gbl... >> The simpler approach will not retain values between postbacks. So you >> set the property, the user clicks a button, and there is another request >> to the server. At this point, this property no longer has the value you >> set. This is because HTTP is stateless, and each request to the server >> means a new page object is created from scratch. >> >> The ViewState approach works, because the viewstate is posted back to the >> server, so the value saved in it can be retrieved. >> >> "Lloyd Dupont" <net.galador@ld> wrote in message >> news:%23VuThc7CGHA.2596@TK2MSFTNGP10.phx.gbl... >>> When you define UserControl in source code the sample I see are often >>> like that: >>> ============ >>> public string Text >>> { >>> get >>> { >>> String s = (String)ViewState["Text"]; >>> return ((s == null) ? String.Empty : s); >>> } >>> set >>> { >>> ViewState["Text"] = value; >>> } >>> } >>> ============ >>> Yet I found that this simpler approach work well >>> ============ >>> string text; >>> public string Text >>> { >>> get { return text; } >>> set { text = value; } >>> } >>> ============ >>> It also doesn't clutter the web page (as the view state is embeded in >>> the page as an input of HIDDEN type). >>> >>> So now I wonder, why use the ViewState exactly? >>> I guess there are reason to do so, like if I want to programatically >>> change the control property with an event handler and keep on further >>> post back. >>> Yet that looks to me as a very marginal exemple. >>> >>> Are there better reason? >>> And how to mark a control in such a way that it won't store its view >>> state in the web page. >>> >>> Such as: I use ViewState to store property (in case they need to be >>> stored), yet I doesn't output this viewstate to the web page, in case it >>> doesn't need to be restored (would be equal to value in the aspx)? >>> Yet that seems quite a marginal >>> >> >> > > ..... I misunderstood you!
In fact I knew that (but maybe my explanation were not very good) and thought you were advocating to use ViewState because of that. And I was replying: it's not a good reason! However I don't understand why you say it has nothing to do with control! If I create a new user control in a web control library, VS.NET creates a template which uses view state like that: ====== public string Text { get { String s = (String)ViewState["Text"]; return ((s == null) ? String.Empty : s); } set { ViewState["Text"] = value; } } ====== And I was wondering: should I use ViewState (which clutter the web page) to store my background color property? Furthermore I was also wondering: is there a way to use the code as below (seemingly using ViewState) but flag the control somehow not to output anything on the page. In such a way another developer could always flag it back to use viewstate (in the page)? Show quoteHide quote "Marina" <someone@nospam.com> wrote in message news:eQ3XtBIDGHA.2300@TK2MSFTNGP15.phx.gbl... > Disagree with what? > > Nothing you just said had anything to do with what I was saying at all. > > Again, defining a property on a page, does not retain the value in that > property between postbacks. > ViewState is maintained between postbacks, since it is sent down with the > page to the browser, and sent up to the server with the post. > > This is just a fact about how things work. There is nothing here about > labels, controls, etc. I'm sorry, but I have no idea what you are talking > about. > > "Lloyd Dupont" <net.galador@ld> wrote in message > news:eMPPjFADGHA.1268@TK2MSFTNGP12.phx.gbl... >>I disagree. >> If it's a valid argument for a textbox, a simple label, which value is >> written in the .aspx, would always have its value set by code / .aspx. >> A label, for instance, only VERY MARGINALLY need to keep its valu between >> postabck. >> (Because its value would most of the time be present in the page trhough >> code or something, and szeldom come from user event) >> >> "Marina" <someone@nospam.com> wrote in message >> news:uBxtpq7CGHA.336@TK2MSFTNGP14.phx.gbl... >>> The simpler approach will not retain values between postbacks. So you >>> set the property, the user clicks a button, and there is another request >>> to the server. At this point, this property no longer has the value you >>> set. This is because HTTP is stateless, and each request to the server >>> means a new page object is created from scratch. >>> >>> The ViewState approach works, because the viewstate is posted back to >>> the server, so the value saved in it can be retrieved. >>> >>> "Lloyd Dupont" <net.galador@ld> wrote in message >>> news:%23VuThc7CGHA.2596@TK2MSFTNGP10.phx.gbl... >>>> When you define UserControl in source code the sample I see are often >>>> like that: >>>> ============ >>>> public string Text >>>> { >>>> get >>>> { >>>> String s = (String)ViewState["Text"]; >>>> return ((s == null) ? String.Empty : s); >>>> } >>>> set >>>> { >>>> ViewState["Text"] = value; >>>> } >>>> } >>>> ============ >>>> Yet I found that this simpler approach work well >>>> ============ >>>> string text; >>>> public string Text >>>> { >>>> get { return text; } >>>> set { text = value; } >>>> } >>>> ============ >>>> It also doesn't clutter the web page (as the view state is embeded in >>>> the page as an input of HIDDEN type). >>>> >>>> So now I wonder, why use the ViewState exactly? >>>> I guess there are reason to do so, like if I want to programatically >>>> change the control property with an event handler and keep on further >>>> post back. >>>> Yet that looks to me as a very marginal exemple. >>>> >>>> Are there better reason? >>>> And how to mark a control in such a way that it won't store its view >>>> state in the web page. >>>> >>>> Such as: I use ViewState to store property (in case they need to be >>>> stored), yet I doesn't output this viewstate to the web page, in case >>>> it doesn't need to be restored (would be equal to value in the aspx)? >>>> Yet that seems quite a marginal >>>> >>> >>> >> >> > > VieState is used to store per user information among each requests and
postback. If you don't store the value in the viewstate, the property value will be lost (since each request instanciate a new webform object), or you will have to set it up again through your code or aspx pages html content. There's other "store" you can use (in .NEt 1.1) - Application : All users store the same Application variables. But beware... if you use web farm, each serveur will have its own application collection - Session : Each user has its own. If you use web farm, you can configure one of the servers to act as a state server, or you can use SQL Server. If you don't, requests may hit another server in the farm and you'll loose the session. - Context : each request hold a context collection that is lost at the end of the request. Usefull if you want to share informations accross all your class and often filed in global.asax My opinion is that the viewstate should be use as soon as you have a value in a control that must persist. Storing it on the client side has the advantage of less memory used on the server (Imagine 100's of variable in the session * number of users --- it can grow very quickly). Ok, it's take some KB on the page, but the most weigth in a page comes from other resources like pictures. Finally, do not forget that a developper that use a control can use the EnableViewState to disable the ability to store data on the client side. Hope that help. Steve "Lloyd Dupont" <net.galador@ld> a écrit dans le message de news: %23VuThc7CGHA.2***@TK2MSFTNGP10.phx.gbl...Show quoteHide quote > When you define UserControl in source code the sample I see are often like > that: > ============ > public string Text > { > get > { > String s = (String)ViewState["Text"]; > return ((s == null) ? String.Empty : s); > } > set > { > ViewState["Text"] = value; > } > } > ============ > Yet I found that this simpler approach work well > ============ > string text; > public string Text > { > get { return text; } > set { text = value; } > } > ============ > It also doesn't clutter the web page (as the view state is embeded in the > page as an input of HIDDEN type). > > So now I wonder, why use the ViewState exactly? > I guess there are reason to do so, like if I want to programatically > change the control property with an event handler and keep on further post > back. > Yet that looks to me as a very marginal exemple. > > Are there better reason? > And how to mark a control in such a way that it won't store its view state > in the web page. > > Such as: I use ViewState to store property (in case they need to be > stored), yet I doesn't output this viewstate to the web page, in case it > doesn't need to be restored (would be equal to value in the aspx)? > Yet that seems quite a marginal > Let's say it differently.
This control of mine is a simple label, the user has no impact on it. Its values are set by code (in OnInit()) and markup tag in the page. Now, why would I need to retain any value between postback? It's clear to me that (thanks to an other poster) I should set EnableViewState = false by default (in the constructor) on this control. Show quoteHide quote "Steve B." <steve_beauge@com.msn_swap_com_and_msn> wrote in message news:umBctr7CGHA.2704@TK2MSFTNGP15.phx.gbl... > VieState is used to store per user information among each requests and > postback. > If you don't store the value in the viewstate, the property value will be > lost (since each request instanciate a new webform object), or you will > have to set it up again through your code or aspx pages html content. > > There's other "store" you can use (in .NEt 1.1) > - Application : All users store the same Application variables. But > beware... if you use web farm, each serveur will have its own application > collection > - Session : Each user has its own. If you use web farm, you can configure > one of the servers to act as a state server, or you can use SQL Server. If > you don't, requests may hit another server in the farm and you'll loose > the session. > - Context : each request hold a context collection that is lost at the end > of the request. Usefull if you want to share informations accross all your > class and often filed in global.asax > > My opinion is that the viewstate should be use as soon as you have a value > in a control that must persist. Storing it on the client side has the > advantage of less memory used on the server (Imagine 100's of variable in > the session * number of users --- it can grow very quickly). > Ok, it's take some KB on the page, but the most weigth in a page comes > from other resources like pictures. > > Finally, do not forget that a developper that use a control can use the > EnableViewState to disable the ability to store data on the client side. > > Hope that help. > > Steve > > "Lloyd Dupont" <net.galador@ld> a écrit dans le message de news: > %23VuThc7CGHA.2***@TK2MSFTNGP10.phx.gbl... >> When you define UserControl in source code the sample I see are often >> like that: >> ============ >> public string Text >> { >> get >> { >> String s = (String)ViewState["Text"]; >> return ((s == null) ? String.Empty : s); >> } >> set >> { >> ViewState["Text"] = value; >> } >> } >> ============ >> Yet I found that this simpler approach work well >> ============ >> string text; >> public string Text >> { >> get { return text; } >> set { text = value; } >> } >> ============ >> It also doesn't clutter the web page (as the view state is embeded in the >> page as an input of HIDDEN type). >> >> So now I wonder, why use the ViewState exactly? >> I guess there are reason to do so, like if I want to programatically >> change the control property with an event handler and keep on further >> post back. >> Yet that looks to me as a very marginal exemple. >> >> Are there better reason? >> And how to mark a control in such a way that it won't store its view >> state in the web page. >> >> Such as: I use ViewState to store property (in case they need to be >> stored), yet I doesn't output this viewstate to the web page, in case it >> doesn't need to be restored (would be equal to value in the aspx)? >> Yet that seems quite a marginal >> > >
Show quote
Hide quote
"Lloyd Dupont" wrote: Lifetime control. Essentially, the User Control properties can fall out of > When you define UserControl in source code the sample I see are often like > that: > ============ > public string Text > { > get > { > String s = (String)ViewState["Text"]; > return ((s == null) ? String.Empty : s); > } > set > { > ViewState["Text"] = value; > } > } > ============ > Yet I found that this simpler approach work well > ============ > string text; > public string Text > { > get { return text; } > set { text = value; } > } > ============ > It also doesn't clutter the web page (as the view state is embeded in the > page as an input of HIDDEN type). > > So now I wonder, why use the ViewState exactly? scope after a request. While setting Text, as a property solves the problem for this request, it does not have lifetime beyond the request. ViewState does. You have other options. Session is an option, although I am not too fond of just throwing things into session as they tend to get "pack ratted" in there and not cleaned out. You can also use caching mechanisms, including custom static (Shared for VBers) classes that use session id to store information. > I guess there are reason to do so, like if I want to programatically change It is marginal in some cases, but being able to hold state on a user control > the control property with an event handler and keep on further post back. > Yet that looks to me as a very marginal exemple. is important when you do postsbacks. > Are there better reason? In the @ directive you can turn off ViewState.> And how to mark a control in such a way that it won't store its view state > in the web page. -- Gregory A. Beamer MVP; MCP: +I, SE, SD, DBA *************************** Think Outside the Box! *************************** mh....
it seeems to be that a much leaner way to define my page would be: - disable view state for the page - enable on a per control basis for those control which have properties that could change from user action (such as text box, gridview, etc...). So I still get "memory" for the controls that can be modified by the user and I don't clutter the page with useless info for these controls which are completely setup in a static way by code or tags. Except for the potential bug that I could "forget" to activate the view state for those contrals that might need it, wouldn't it be better (leaner) way? Show quoteHide quote "Cowboy (Gregory A. Beamer) - MVP" <NoSpamMgbworld@comcast.netNoSpamM> wrote in message news:92B796E1-CC59-4918-9F9E-49D42D2051BF@microsoft.com... > > > > "Lloyd Dupont" wrote: > >> When you define UserControl in source code the sample I see are often >> like >> that: >> ============ >> public string Text >> { >> get >> { >> String s = (String)ViewState["Text"]; >> return ((s == null) ? String.Empty : s); >> } >> set >> { >> ViewState["Text"] = value; >> } >> } >> ============ >> Yet I found that this simpler approach work well >> ============ >> string text; >> public string Text >> { >> get { return text; } >> set { text = value; } >> } >> ============ >> It also doesn't clutter the web page (as the view state is embeded in the >> page as an input of HIDDEN type). >> >> So now I wonder, why use the ViewState exactly? > > Lifetime control. Essentially, the User Control properties can fall out of > scope after a request. While setting Text, as a property solves the > problem > for this request, it does not have lifetime beyond the request. ViewState > does. > > You have other options. Session is an option, although I am not too fond > of > just throwing things into session as they tend to get "pack ratted" in > there > and not cleaned out. You can also use caching mechanisms, including custom > static (Shared for VBers) classes that use session id to store > information. > >> I guess there are reason to do so, like if I want to programatically >> change >> the control property with an event handler and keep on further post back. >> Yet that looks to me as a very marginal exemple. > > It is marginal in some cases, but being able to hold state on a user > control > is important when you do postsbacks. > >> Are there better reason? >> And how to mark a control in such a way that it won't store its view >> state >> in the web page. > > In the @ directive you can turn off ViewState. > > -- > Gregory A. Beamer > MVP; MCP: +I, SE, SD, DBA > > *************************** > Think Outside the Box! > *************************** For instance my control is a collapsible table with rounded corner.
It has 6 relevant values: - expanded state - show (or not) expand/collapse button - page color (for rounded boder dynamic picture) - border & header color - inside color - width Yet only the expanded state would obviously need to be saved (although I'm not sure I could pass this back to the web server, the viewstate is no good because that needs to be modified via javascript, maybe through a cookie?) Save all that stuff in the viewstate seems quite to be useless clutter to me. Although I could imagine this control being used in a page, and change its color according to some user action (for example), I'm sure this state would be more efficiently stored elsewhere. So the question is: - should I (could I?) set EnableViewState = false in the constructor ? (or OnInit()?) - should I not use view state at all and use instance variable?  
Other interesting topics
Nested asp.net application
Excluding files Basic formatting for HTML in ASP.NET 1.1 ? What caused the postback? Access to a HiddenFiled in a Content control from javaScript Session variable scope in a Load Balanced environment timer functionality in .net masking url in datagrid hyperlink column in status bar Scrollbar in gridview Erro no start pag |
|||||||||||||||||||||||
