viewstate big

[Nick C]

Hi

How can i reduce the viewstate for my asp.net application. It is getting
very large now. What is a good solution?

thanks

N

 

[Juan T. Llibre]

re:
!> How can i reduce the viewstate for my asp.net application.

<%@ Page Language="C#" EnableViewState="false" %>

or

<%@ Page Language="VB" EnableViewState="false" %>

 

[Michael Nemtsev]

Hello Nick,

just turn viewstate off for the controls.
In case of grid, consider avoid using datagrid and switch to gridview

See there http://msdn.microsoft.com/msdnmag/issues/04/10/ViewState/


---
WBR, Michael Nemtsev [.NET/C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

NC> Hi
NC>
NC> How can i reduce the viewstate for my asp.net application. It is
NC> getting very large now. What is a good solution?
NC>
NC> thanks
NC>
NC> N
NC>

 

[Eliyahu Goldin]

Be careful, in many cases viewstate needs to be enabled. You can set
EnableViewState="false" on the page level and EnableViewState="true" for
individual controls that need it.

--
Eliyahu Goldin,
Software Developer & Consultant
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin
http://usableasp.net

 

[Mark Rae]

Be careful, in many cases viewstate needs to be enabled. You can set
EnableViewState="false" on the page level and EnableViewState="true" for
individual controls that need it.

That's what I do...

 

[Mark Rae]

In case of grid, consider avoid using datagrid and switch to gridview

Yes indeed - and there are many other good reasons to prefer GridView to
DataGrid...

 

[Juan T. Llibre]

re:
!> Be careful, in many cases viewstate needs to be enabled.

Which cases *need* viewstate ?

I've never missed viewstate because I never program against the viewstate.

I prefer alternate methods of persisting the page/control info viewstate persists.
Viewstate is only one of several ways to persist page/control info you're interested in.

Viewstate contains all of a page's information *except* the data
which is available in the Request.Form collection, (PostData).

ASP.NET automatically populates control values with the data from Request.Form,
however, and I prefer using Session values to persist other types of data.

Be careful, in many cases viewstate needs to be enabled. You can set EnableViewState="false" on
the page level and EnableViewState="true" for individual controls that need it.

--
Eliyahu Goldin,
Software Developer & Consultant
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin
http://usableasp.net

re:
!> How can i reduce the viewstate for my asp.net application.

<%@ Page Language="C#" EnableViewState="false" %>

or

<%@ Page Language="VB" EnableViewState="false" %>

 

[Eliyahu Goldin]

I do use viewstate for persisting, mostly for storing small pieces of data
like boolean and integer properties. But in this aspect you are right, you
can persist data in other ways.

What viewstate is indeed necessary for is keeping control state between
postbacks. A simple example: item selection in a dropdown list. With
viewstate disabled you won't know what item is selected. And you will have
to re-populate the ddl on every postback.

--
Eliyahu Goldin,
Software Developer & Consultant
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin
http://usableasp.net

re:
!> Be careful, in many cases viewstate needs to be enabled.

Which cases *need* viewstate ?

I've never missed viewstate because I never program against the viewstate.

I prefer alternate methods of persisting the page/control info viewstate
persists.
Viewstate is only one of several ways to persist page/control info you're
interested in.

Viewstate contains all of a page's information *except* the data
which is available in the Request.Form collection, (PostData).

ASP.NET automatically populates control values with the data from
Request.Form,
however, and I prefer using Session values to persist other types of data.





message

Be careful, in many cases viewstate needs to be enabled. You can set
EnableViewState="false" on
the page level and EnableViewState="true" for individual controls that
need it.

--
Eliyahu Goldin,
Software Developer & Consultant
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin
http://usableasp.net

re:
!> How can i reduce the viewstate for my asp.net application.

<%@ Page Language="C#" EnableViewState="false" %>

or

<%@ Page Language="VB" EnableViewState="false" %>




Hi

How can i reduce the viewstate for my asp.net application. It is
getting very large now. What is
a good solution?

thanks

N

 

[Michael Nemtsev]

Hello Eliyahu,

For such cases the ControlState was introduced in ASP.net 2.0, where all
critical info can be persisted even if viewstate is turned off

---
WBR, Michael Nemtsev [.NET/C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

EG> I do use viewstate for persisting, mostly for storing small pieces
EG> of data like boolean and integer properties. But in this aspect you
EG> are right, you can persist data in other ways.
EG>
EG> What viewstate is indeed necessary for is keeping control state
EG> between postbacks. A simple example: item selection in a dropdown
EG> list. With viewstate disabled you won't know what item is selected.
EG> And you will have to re-populate the ddl on every postback
EG>

 

[Raaj]

Juan,

I've never missed viewstate because I never program against the viewstate.

So, How do you manage (without viewstate) to track declarative and
dynamic changes to the properties of server controls?

I prefer alternate methods of persisting the page/control info viewstate persists.
Viewstate is only one of several ways to persist page/control info you're interested in.

What are such alternate methods?

ASP.NET automatically populates control values with the data from Request.Form,
however, and I prefer using Session values to persist other types of data.

True, as long as the controls implement IPostBackDataHandler
interface. But somehow I'am not quite sure where do you persist the
controls properties state without viewstate

I am not trying to be nit picky, curious to know how you are managing
things differently.

Raaj

re:
!> Be careful, in many cases viewstate needs to be enabled.

Which cases *need* viewstate ?

I've never missed viewstate because I never program against the viewstate.

I prefer alternate methods of persisting the page/control info viewstate persists.
Viewstate is only one of several ways to persist page/control info you're interested in.

Viewstate contains all of a page's information *except* the data
which is available in the Request.Form collection, (PostData).

ASP.NET automatically populates control values with the data from Request..Form,
however, and I prefer using Session values to persist other types of data.

Juan T. Llibre, asp.net MVP
asp.net faq :http://asp.net.do/faq/
foros de asp.net, en español :http://asp.net.do/foros/

Be careful, in many cases viewstate needs to be enabled. You can set EnableViewState="false" on
the page level and EnableViewState="true" for individual controls that need it.

--
Eliyahu Goldin,
Software Developer & Consultant
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin
http://usableasp.net

- Show quoted text -

 

[Juan T. Llibre]

re:
!> So, How do you manage (without viewstate) to track declarative and
!> dynamic changes to the properties of server controls?

Can you describe a real-life example of needing to do that with viewstate ?

re:
!> What are such alternate methods?

ControlState:

http://msdn2.microsoft.com/en-us/library/ms178577.aspx

re:
!> somehow I'am not quite sure where do you persist the
!> controls properties state without viewstate

Read up on ControlState.

To read Microsoft's recommendations for maintaining state across a wide range of properties, see :

http://msdn2.microsoft.com/en-us/library/z1hkazw7.aspx




Juan,

I've never missed viewstate because I never program against the viewstate.

So, How do you manage (without viewstate) to track declarative and
dynamic changes to the properties of server controls?

I prefer alternate methods of persisting the page/control info viewstate persists.
Viewstate is only one of several ways to persist page/control info you're interested in.

What are such alternate methods?

ASP.NET automatically populates control values with the data from Request.Form,
however, and I prefer using Session values to persist other types of data.

True, as long as the controls implement IPostBackDataHandler
interface. But somehow I'am not quite sure where do you persist the
controls properties state without viewstate

I am not trying to be nit picky, curious to know how you are managing
things differently.

Raaj

re:
!> Be careful, in many cases viewstate needs to be enabled.

Which cases *need* viewstate ?

I've never missed viewstate because I never program against the viewstate.

I prefer alternate methods of persisting the page/control info viewstate persists.
Viewstate is only one of several ways to persist page/control info you're interested in.

Viewstate contains all of a page's information *except* the data
which is available in the Request.Form collection, (PostData).

ASP.NET automatically populates control values with the data from Request.Form,
however, and I prefer using Session values to persist other types of data.

"Eliyahu Goldin" <[email protected]>
wrote in message

Be careful, in many cases viewstate needs to be enabled. You can set EnableViewState="false" on
the page level and EnableViewState="true" for individual controls that need it.

--
Eliyahu Goldin,
Software Developer & Consultant
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin
http://usableasp.net

- Show quoted text -

 

[Raaj]

To be clear by viewstate I am referring to hidden form fields
(explanation below)

re:

!> What are such alternate methods?

ControlState:
http://msdn2.microsoft.com/en-us/library/ms178577.aspx

I still wonder if this makes a difference. Isn't the bulk of control
state still persisted in the hidden _viewstate field, eventually the
state of the controls go through the round trip
So if the original post was restated as "How can I reduce the hidden
fields for my asp.net application? It is getting very large now. What
is a good solution? "What would be the probable answer?

re:
!> So, How do you manage (without viewstate) to track declarative and
!> dynamic changes to the properties of server controls?

Can you describe a real-life example of needing to do that with viewstate ?

Assuming we are extending a web control and say we created a new
property as part of this control. The user of this control sets the
initial value of the property declaratively through the property
window or as part of the html markup. Now one of the server side event
changes the value of this property, where is the new value stored, how
will the framework track the changes to the property, what are the
placeholders for the framework to determine if the value is dirty. I
presume everything does eventually end up in hidden fields, don't
they?

I prefer alternate methods of persisting the page/control info viewstate persists

It appears you are persisting the state of the controls through the
hidden fields

re:
!> So, How do you manage (without viewstate) to track declarative and
!> dynamic changes to the properties of server controls?

Can you describe a real-life example of needing to do that with viewstate ?

re:
!> What are such alternate methods?

ControlState:

http://msdn2.microsoft.com/en-us/library/ms178577.aspx

re:
!> somehow I'am not quite sure where do you persist the
!> controls properties state without viewstate

Read up on ControlState.

To read Microsoft's recommendations for maintaining state across a wide range of properties, see :

http://msdn2.microsoft.com/en-us/library/z1hkazw7.aspx

Juan T. Llibre, asp.net MVP
asp.net faq :http://asp.net.do/faq/
foros de asp.net, en español :http://asp.net.do/foros/

Juan,

I've never missed viewstate because I never program against the viewstate.

So, How do you manage (without viewstate) to track declarative and
dynamic changes to the properties of server controls?

I prefer alternate methods of persisting the page/control info viewstate persists.
Viewstate is only one of several ways to persist page/control info you're interested in.

What are such alternate methods?

ASP.NET automatically populates control values with the data from Request.Form,
however, and I prefer using Session values to persist other types of data.

True, as long as the controls implement IPostBackDataHandler
interface. But somehow I'am not quite sure where do you persist the
controls properties state without viewstate

I am not trying to be nit picky, curious to know how you are managing
things differently.

Raaj

re:
!> Be careful, in many cases viewstate needs to be enabled.

Which cases *need* viewstate ?

I've never missed viewstate because I never program against the viewstate.

I prefer alternate methods of persisting the page/control info viewstate persists.
Viewstate is only one of several ways to persist page/control info you're interested in.

Viewstate contains all of a page's information *except* the data
which is available in the Request.Form collection, (PostData).

ASP.NET automatically populates control values with the data from Request.Form,
however, and I prefer using Session values to persist other types of data.

"Eliyahu Goldin" <[email protected]>
wrote in message

news:[email protected]...

Be careful, in many cases viewstate needs to be enabled. You can set EnableViewState="false" on
the page level and EnableViewState="true" for individual controls that need it.
--
Eliyahu Goldin,
Software Developer & Consultant
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin
http://usableasp.net
re:
!> How can i reduce the viewstate for my asp.net application.
<%@ Page Language="C#" EnableViewState="false" %>
or
<%@ Page Language="VB" EnableViewState="false" %>

Hi
How can i reduce the viewstate for my asp.net application. It is getting very large now. What
is
a good solution?
thanks
N- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

 

[Juan T. Llibre]

re:
!> To be clear by viewstate I am referring to hidden form fields

You mean that viewstate uses *one* hidden field ( singular ).
Other hidden fields don't hold StateBag information.

re:
!> ControlState:
!> http://msdn2.microsoft.com/en-us/library/ms178577.aspx
!> Isn't the bulk of control state still persisted in the hidden _viewstate field ?

No. You don't have to have Viewstate enabled in order to be able to use ControlState.

Review the link provided above...

re:
!> Assuming we are extending a web control and say we created a new property as part
!> of this control. The user of this control sets the initial value of the property declaratively
!> through the property window or as part of the html markup.

!> Now one of the server side event changes the value of this property, where is the
!> new value stored, how will the framework track the changes to the property,
!> what are the placeholders for the framework to determine if the value is dirty.

While that sounds like an interesting theoretical proposition,
I haven't found the need to do that in any application I've developed.

re:
!> I presume everything does eventually end up in hidden fields, don't they?

You may be presuming a bit too much.

;-)






To be clear by viewstate I am referring to hidden form fields
(explanation below)

re:

!> What are such alternate methods?

ControlState:
http://msdn2.microsoft.com/en-us/library/ms178577.aspx

I still wonder if this makes a difference. Isn't the bulk of control
state still persisted in the hidden _viewstate field, eventually the
state of the controls go through the round trip
So if the original post was restated as "How can I reduce the hidden
fields for my asp.net application? It is getting very large now. What
is a good solution? "What would be the probable answer?

re:
!> So, How do you manage (without viewstate) to track declarative and
!> dynamic changes to the properties of server controls?

Can you describe a real-life example of needing to do that with viewstate ?

Assuming we are extending a web control and say we created a new property as part
of this control. The user of this control sets the initial value of the property declaratively
through the property window or as part of the html markup.

Now one of the server side event changes the value of this property, where is the
new value stored, how will the framework track the changes to the property,
what are the placeholders for the framework to determine if the value is dirty.

I presume everything does eventually end up in hidden fields, don't they?

I prefer alternate methods of persisting the page/control info viewstate persists

It appears you are persisting the state of the controls through the
hidden fields

re:
!> So, How do you manage (without viewstate) to track declarative and
!> dynamic changes to the properties of server controls?

Can you describe a real-life example of needing to do that with viewstate ?

re:
!> What are such alternate methods?

ControlState:

http://msdn2.microsoft.com/en-us/library/ms178577.aspx

re:
!> somehow I'am not quite sure where do you persist the
!> controls properties state without viewstate

Read up on ControlState.

To read Microsoft's recommendations for maintaining state across a wide range of properties, see :

http://msdn2.microsoft.com/en-us/library/z1hkazw7.aspx

Juan T. Llibre, asp.net MVP
asp.net faq :http://asp.net.do/faq/
foros de asp.net, en español :http://asp.net.do/foros/

Juan,

I've never missed viewstate because I never program against the viewstate.

So, How do you manage (without viewstate) to track declarative and
dynamic changes to the properties of server controls?

I prefer alternate methods of persisting the page/control info viewstate persists.
Viewstate is only one of several ways to persist page/control info you're interested in.

What are such alternate methods?

ASP.NET automatically populates control values with the data from Request.Form,
however, and I prefer using Session values to persist other types of data.

True, as long as the controls implement IPostBackDataHandler
interface. But somehow I'am not quite sure where do you persist the
controls properties state without viewstate

I am not trying to be nit picky, curious to know how you are managing
things differently.

Raaj

re:
!> Be careful, in many cases viewstate needs to be enabled.

Which cases *need* viewstate ?

I've never missed viewstate because I never program against the viewstate.

I prefer alternate methods of persisting the page/control info viewstate persists.
Viewstate is only one of several ways to persist page/control info you're interested in.

Viewstate contains all of a page's information *except* the data
which is available in the Request.Form collection, (PostData).

ASP.NET automatically populates control values with the data from Request.Form,
however, and I prefer using Session values to persist other types of data.

"Eliyahu Goldin"
<[email protected]>
wrote in message

news:[email protected]...

Be careful, in many cases viewstate needs to be enabled. You can set EnableViewState="false"
on
the page level and EnableViewState="true" for individual controls that need it.
--
Eliyahu Goldin,
Software Developer & Consultant
Microsoft MVP [ASP.NET]
http://msmvps.com/blogs/egoldin
http://usableasp.net
re:
!> How can i reduce the viewstate for my asp.net application.
<%@ Page Language="C#" EnableViewState="false" %>
or
<%@ Page Language="VB" EnableViewState="false" %>

Hi
How can i reduce the viewstate for my asp.net application. It is getting very large now.
What
is
a good solution?
thanks
N- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -