Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > How do I know when to use the Viewstate and when to use the posted data? :-)

Reply
Thread Tools

How do I know when to use the Viewstate and when to use the posted data? :-)

 
 
Simon
Guest
Posts: n/a
 
      11-09-2004
Hi everyone,

I have a quick question that I hope someone can help me with:

I've made a user control that contains a text box and some validation
functionality. This control has a few extra properties declared on it over
and above that provided by the textbox.

As I understand it, part of the process to make this work is, in the
property accessor's for the properties that you wish to persist you add
values to the ViewState and you remove values to the viewstate. I don't
quite understand why yet but I think its something to do with maintaining
state over postbacks.

OK so far.

When my control is loaded, it goes to the database and gets the information
it needs to display. I'm not sure if I'm doing the right thing here or not,
but I'll explicitly state my question in a couple of second.

Once it gets the data it needs, it uses the set property accessors to
initialise the control and have the values dropped into viewstate.

When the page load in front of the user it seems to me that the page will
have the values of internal controls actually in the controls themselves (as
you'd expect), but also in the viewstate. Fair enough.

My actual question is related to the following:

When the user hits a submit button on the page amongst the other things that
occur, the following happens:

1. The values of the controls are posted back to me. If the user has changed
any values in the textboxes or so on, thats where the changed will be (I
think).

2. Somehow, the viewstate is made available. I'm guessing that it's posted
back as well, which seems a bit of duplicated effort but never mind but I
guess the viewstate and the post variables may contain different info on
occasions that the user has changed a value on the page. I dont have time to
worry about that just now unfortunately.

Question:

Given that I have the viewstate and then also the actual values posted
straight from the controls themselves the question is, do I just ignore the
viewstate because it doesnt contain the most recent values or do I have to
pay attention to it somehow. If the former is the case, then I don't see the
point in the viewstate. If the later is the case, then I still don't see the
point of the viewstate because as I understand it, all its going to contain
is the values that were sent to the page on the way out. The value in the
viewstate won't have changed when they come back in on a postback. The
values of the controls may have been changed by the user, but then thats
seperate from the viewstate (I think).

If anyone can help me understand this without using the phrase "Viewstate is
used to persist form values over postbacks" or something to that effect,
then I would be very greatful.

With many thanks in advance

Simon


 
Reply With Quote
 
 
 
 
Henri
Guest
Posts: n/a
 
      11-09-2004
Hi Simon,

As far as I know, Viewstate is used to persist form values over postbacks
only when you want to know if value has changed.

For instance, try this :
<input runat="server" type="text" name="myHtmlInputText" />
You don't specify that you want to know if value has changed between posts,
so viewstate isn't used (try it with trace="true") but the value is still
persisted.

Now if you write :
<input runat="server" type="text" name="myHtmlInputText"
onServerChange="myHtmlInputText_ServerChange" />
You specify that you want to call myHtmlInputText_ServerChange when value
has changed, so ViewState is used here: old value is saved in viewstate and
then compared to the new one from Input to detect a change.

Hope it helps
Sorry for my bad English
Henri

"Simon" <sh856531@microsofts_free_email_service.com> a écrit dans le message
de news:(E-Mail Removed)...
> Hi everyone,
>
> I have a quick question that I hope someone can help me with:
>
> I've made a user control that contains a text box and some validation
> functionality. This control has a few extra properties declared on it over
> and above that provided by the textbox.
>
> As I understand it, part of the process to make this work is, in the
> property accessor's for the properties that you wish to persist you add
> values to the ViewState and you remove values to the viewstate. I don't
> quite understand why yet but I think its something to do with maintaining
> state over postbacks.
>
> OK so far.
>
> When my control is loaded, it goes to the database and gets the

information
> it needs to display. I'm not sure if I'm doing the right thing here or

not,
> but I'll explicitly state my question in a couple of second.
>
> Once it gets the data it needs, it uses the set property accessors to
> initialise the control and have the values dropped into viewstate.
>
> When the page load in front of the user it seems to me that the page will
> have the values of internal controls actually in the controls themselves

(as
> you'd expect), but also in the viewstate. Fair enough.
>
> My actual question is related to the following:
>
> When the user hits a submit button on the page amongst the other things

that
> occur, the following happens:
>
> 1. The values of the controls are posted back to me. If the user has

changed
> any values in the textboxes or so on, thats where the changed will be (I
> think).
>
> 2. Somehow, the viewstate is made available. I'm guessing that it's posted
> back as well, which seems a bit of duplicated effort but never mind but I
> guess the viewstate and the post variables may contain different info on
> occasions that the user has changed a value on the page. I dont have time

to
> worry about that just now unfortunately.
>
> Question:
>
> Given that I have the viewstate and then also the actual values posted
> straight from the controls themselves the question is, do I just ignore

the
> viewstate because it doesnt contain the most recent values or do I have to
> pay attention to it somehow. If the former is the case, then I don't see

the
> point in the viewstate. If the later is the case, then I still don't see

the
> point of the viewstate because as I understand it, all its going to

contain
> is the values that were sent to the page on the way out. The value in the
> viewstate won't have changed when they come back in on a postback. The
> values of the controls may have been changed by the user, but then thats
> seperate from the viewstate (I think).
>
> If anyone can help me understand this without using the phrase "Viewstate

is
> used to persist form values over postbacks" or something to that effect,
> then I would be very greatful.
>
> With many thanks in advance
>
> Simon
>
>
>




 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ViewState and posted back data Tumurbaatar S. ASP .Net Building Controls 1 11-29-2005 03:10 PM
Datagrid, posted data, and viewstate size rgouge ASP .Net 0 07-29-2005 04:39 PM
How do I know when to use the Viewstate and when to use the posted data? :-) Simon ASP .Net Web Controls 1 11-09-2004 02:32 AM
I know, I know, I don't know Andries Perl Misc 3 04-23-2004 02:17 AM
Getting rid of viewstate in GET posted forms damonf ASP .Net 2 11-08-2003 07:58 PM



Advertisments