What's better, a hidden form field or viewstate?

[Alan Silver]

Hello,

I have a page that gets passed an ID in the query string. It then uses
this ID to pull info out of a database and populate controls on the
page. When the page is posted back, the query string is not going to be
there any more, so I need some way of storing the ID.

What's the best way of doing this? The obvious thought is a hidden form
field, but there doesn't seem to be a web control for this. Do I just
use an ordinary HTML control?

The other thought I had was to put the ID in the viewstate, but this
sounds a bit over the top, plus it has the risk that the value might be
dropped form the viewstate.

I don't want to store it in the Session as that times out.

Any comments? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)

[Eliyahu Goldin]

A hidden form field is used if you need to pass values between server and
client. If all you need is just to persist a value between postbacks, use
viewstate.

Eliyahu

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:1F**************@nospamthankyou.spam...

Hello,

I have a page that gets passed an ID in the query string. It then uses
this ID to pull info out of a database and populate controls on the
page. When the page is posted back, the query string is not going to be
there any more, so I need some way of storing the ID.

What's the best way of doing this? The obvious thought is a hidden form
field, but there doesn't seem to be a web control for this. Do I just
use an ordinary HTML control?

The other thought I had was to put the ID in the viewstate, but this
sounds a bit over the top, plus it has the risk that the value might be
dropped form the viewstate.

I don't want to store it in the Session as that times out.

Any comments? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)

[Tom.PesterDELETETHISSS]

Viewstate is also put in a hidden form field so there is no big difference
other than that viewstate is easier.

Let me know if you have any more questions..

Cheers,
Tom Pester

Hello,

I have a page that gets passed an ID in the query string. It then uses
this ID to pull info out of a database and populate controls on the
page. When the page is posted back, the query string is not going to
be there any more, so I need some way of storing the ID.

What's the best way of doing this? The obvious thought is a hidden
form field, but there doesn't seem to be a web control for this. Do I
just use an ordinary HTML control?

The other thought I had was to put the ID in the viewstate, but this
sounds a bit over the top, plus it has the risk that the value might
be dropped form the viewstate.

I don't want to store it in the Session as that times out.

Any comments? TIA

[Andy Rose]

I agree with the previous posts, viewstate is easiest.
If you did want to use a hidden field with a dynamic value you can add a
'Literal' web control to your form and set it's text property during the Page
Load to:

"<input type='hidden' id='hiddenField' value='" + ID + "'>";

"To********************@pandora.be" wrote:

Viewstate is also put in a hidden form field so there is no big difference
other than that viewstate is easier.

Let me know if you have any more questions..

Cheers,
Tom Pester

Hello,

I have a page that gets passed an ID in the query string. It then uses
this ID to pull info out of a database and populate controls on the
page. When the page is posted back, the query string is not going to
be there any more, so I need some way of storing the ID.

What's the best way of doing this? The obvious thought is a hidden
form field, but there doesn't seem to be a web control for this. Do I
just use an ordinary HTML control?

The other thought I had was to put the ID in the viewstate, but this
sounds a bit over the top, plus it has the risk that the value might
be dropped form the viewstate.

I don't want to store it in the Session as that times out.

Any comments? TIA

[Alan Silver]

>A hidden form field is used if you need to pass values between server and

client. If all you need is just to persist a value between postbacks, use
viewstate.
Thanks to both of you.
Eliyahu

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:1F**************@nospamthankyou.spam...

Hello,

I have a page that gets passed an ID in the query string. It then uses
this ID to pull info out of a database and populate controls on the
page. When the page is posted back, the query string is not going to be
there any more, so I need some way of storing the ID.

What's the best way of doing this? The obvious thought is a hidden form
field, but there doesn't seem to be a web control for this. Do I just
use an ordinary HTML control?

The other thought I had was to put the ID in the viewstate, but this
sounds a bit over the top, plus it has the risk that the value might be
dropped form the viewstate.

I don't want to store it in the Session as that times out.

Any comments? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)

--
Alan Silver
(anything added below this line is nothing to do with me)

[Michael Baltic]

If you use a hidden field, you can access it on the aspx page code behind by
declaring it runat='server' and adding it to the list of controls in the
codebehind.

Like this (VB.NET example):

aspx page: <input type="hidden" name="hControlName" id="hControlName"
runat="server">

code behind: Protected WithEvents hControlName As
System.Web.UI.HtmlControls.HtmlInputHidden

dim ID as System.Int32 = CType(hControlName.Value, System.Int32)

--
Staff Consultant II - Enterprise Web Services - Cardinal Solutions Group

Future Business Model - National City Mortgage
"To********************@pandora.be" wrote:

Viewstate is also put in a hidden form field so there is no big difference
other than that viewstate is easier.

Let me know if you have any more questions..

Cheers,
Tom Pester

Hello,

I have a page that gets passed an ID in the query string. It then uses
this ID to pull info out of a database and populate controls on the
page. When the page is posted back, the query string is not going to
be there any more, so I need some way of storing the ID.

What's the best way of doing this? The obvious thought is a hidden
form field, but there doesn't seem to be a web control for this. Do I
just use an ordinary HTML control?

The other thought I had was to put the ID in the viewstate, but this
sounds a bit over the top, plus it has the risk that the value might
be dropped form the viewstate.

I don't want to store it in the Session as that times out.

Any comments? TIA

[Hans Kesting]

Alan Silver wrote:

Hello,

I have a page that gets passed an ID in the query string. It then uses
this ID to pull info out of a database and populate controls on the
page. When the page is posted back, the query string is not going to
be there any more, so I need some way of storing the ID.

What's the best way of doing this? The obvious thought is a hidden
form field, but there doesn't seem to be a web control for this. Do I
just use an ordinary HTML control?

The other thought I had was to put the ID in the viewstate, but this
sounds a bit over the top, plus it has the risk that the value might
be dropped form the viewstate.

I don't want to store it in the Session as that times out.

Any comments? TIA

If it's just an ID, what about storing it in a cookie? That will keep
it's value even if the user clicks a link (which would lose the value
of hidden fields, such as viewstate). You can choose between
persisted and non-persisted cookies, depending on further requirements.

Hans Kesting

[Mythran]

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:1F**************@nospamthankyou.spam...

Hello,

I have a page that gets passed an ID in the query string. It then uses
this ID to pull info out of a database and populate controls on the page.
When the page is posted back, the query string is not going to be there
any more, so I need some way of storing the ID.

What's the best way of doing this? The obvious thought is a hidden form
field, but there doesn't seem to be a web control for this. Do I just use
an ordinary HTML control?

The other thought I had was to put the ID in the viewstate, but this
sounds a bit over the top, plus it has the risk that the value might be
dropped form the viewstate.

I don't want to store it in the Session as that times out.

Any comments? TIA

--
Alan Silver
(anything added below this line is nothing to do with me)

The viewstate is a name-value pair collection class that is serialized and
written to the client as 1 field. I am not sure if it is compressed at all
(documentation doesn't say afaik). In any case, use the ViewState if all
you are doin' is persisting across postbacks. If you need to access the
data on the client-side using client-side script, you should use a hidden
field.

Another way, just to throw this out there, is to use a TextBox WebControl
and add the following to make it hidden (behave sorta like a hidden
control):

TextBox1.Attributes.Add("display", "none")

HTH,
Mythran

[Alan Silver]

>If it's just an ID, what about storing it in a cookie? That will keep

it's value even if the user clicks a link (which would lose the value
of hidden fields, such as viewstate). You can choose between persisted
and non-persisted cookies, depending on further requirements.

Thanks, but I don't want to use cookies. The ID is only for use between
postbacks to the same page, so I don't need to persist it across other
pages. Also, you can't always be sure the user has cookies enabled.

Thanks for the reply

--
Alan Silver
(anything added below this line is nothing to do with me)

[Alan Silver]

>If you use a hidden field, you can access it on the aspx page code behind by

declaring it runat='server' and adding it to the list of controls in the
codebehind.

That's basically what I did, only in C# ;-)

Thanks for the reply.

--
Alan Silver
(anything added below this line is nothing to do with me)

[Mythran]

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:OZ**************@nospamthankyou.spam...

Also, you can't always be sure the user has cookies enabled.

Well, if you make use of the Session var, and it is used InProc, it uses a
Cookie to track the SessionId for the client :)

Mythran

[Tom.PesterDELETETHISSS]

Thats a session cookie and most people allow that kind. Its the persistent
cookies that get blokked.
Cheers,
Tom Pester

"Alan Silver" <al*********@nospam.thanx> wrote in message
news:OZ**************@nospamthankyou.spam...

Also, you can't always be sure the user has cookies enabled.

Well, if you make use of the Session var, and it is used InProc, it
uses a Cookie to track the SessionId for the client :)

Mythran

[Alan Silver]

>> Also, you can't always be sure the user has cookies enabled.

Well, if you make use of the Session var, and it is used InProc, it
uses a Cookie to track the SessionId for the client :)

True, but I don't want to use cookies in this case anyway ;-)

Thanks for the reply

--
Alan Silver
(anything added below this line is nothing to do with me)