ViewState: why?

[Lloyd Dupont]

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

 

[Remy]

All ASP.NET Controls have a property called EnableViewState, you can
disable that if you don't need the viewstate.

Remy Blaettler

 

[Marina]

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.

 

[Steve B.]

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

 

[Guest]

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!
***************************

 

[Lloyd Dupont]

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)

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.

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

 

[Lloyd Dupont]

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.

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

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

 

[Lloyd Dupont]

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?

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!
***************************

 

[Lloyd Dupont]

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?

 

[Marina]

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.

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)

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.

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

 

[Lloyd Dupont]

..... 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)?

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.

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)

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.

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