"Joakim Westman (Elicit AB)" <_n*********************@elicit.se> wrote in
message news:uT**************@tk2msftngp13.phx.gbl...
Hi!
I have a page that generates a lot of HTML, and I am considering different
solutions to constrain the amount of
code that is sent back to the client.
One thing I thought about is the viewstate which is fairly large for this
application.
This is certainly possible. Before making this determination, look at the
actual size of the code sent by getting the file size out of your Internet
cache. You may find that, despite looks, it is only a few kb.
Does anybody have any experience on storing viewstate in Session.
If you mean actually storing that string in Session? Hold out your knuckles!
Whack! Whack! Whack!
If you mean storing the info/variables, sure, you can do that. Consider some
different store, however, as it is unlikely you are using all of the info
with every page hit. Only store stuff in session that is used very
frequently. The rest should be put in a persistant store, like a database.
I know that sessionState has a mode for storing inProc, SqlServer etc, but
I doesn't seem like viewstate has come this far yet.
I know there are methods to override to do this, but will it work out you
think?
ViewState will NEVER come "this far". ViewState is a method of working state
into a stateless environment. As the entire contents are stored in an
encrypted string, you do not need anything else to complete a transaction
with the user. You do not need session state, you do not need
authentication. Etc. Etc. It is not the best method for every application,
however.
The basic idea here is ViewState is meant to be sent to the client, period.
Storing in Session, SQL Server, et al, puts the data on the Server, not the
client. This is not the design goal for ViewState.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
************************************************** ********************
Think Outside the Box!
************************************************** ********************
