By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,319 Members | 2,361 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,319 IT Pros & Developers. It's quick & easy.

Request.form("max")

P: n/a
I can get the value on the form at the server side by using

Request.form("max")

when max field is disabled I dont get value. For GUI and business logic
purpose I have disabled some fields with the values, but when I update
Request.form does not return me anything for disabled fields.

How to read disabled fields at the server side
Mar 22 '06 #1
Share this Question
Share on Google+
8 Replies


P: n/a
abcd wrote:
when max field is disabled I dont get value. For GUI and
business logic purpose I have disabled some fields with
the values, but when I update Request.form does not return
me anything for disabled fields.

How to read disabled fields at the server side


You can't:
http://www.w3.org/TR/html401/interac...ssful-controls

One alternative is to use READONLY instead of DISABLED.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Mar 22 '06 #2

P: n/a
"abcd" <ab**@abcd.com> wrote:
I can get the value on the form at the server side by using

Request.form("max")

when max field is disabled I dont get value. For GUI and business logic
purpose I have disabled some fields with the values, but when I update
Request.form does not return me anything for disabled fields.

How to read disabled fields at the server side

If Not isEmpty(Request.Form("max")) Then
' there was a "max" parameter in this form
Else
' there was no "max" parameter in this form
End If

--
Tim Slattery
MS MVP(DTS)
Sl********@bls.gov
Mar 23 '06 #3

P: n/a
Tim Slattery wrote:
How to read disabled fields at the server side


If Not isEmpty(Request.Form("max")) Then
' there was a "max" parameter in this form
Else
' there was no "max" parameter in this form
End If


That's not quite the issue, Tim. By specification, a disabled element cannot
be successful. That means no name-value pair for that element in the request
(and hence, no corresponding item in the Request.Form collection). Absence
from the request does not signify absence from the form, however.

And indeed, he wants the value of that element. He wants it to show up in
the Request.Form collection. He just does not want to make it convenient for
the user to access that value directly.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Mar 23 '06 #4

P: n/a
Dave Anderson wrote on 23 mrt 2006 in
microsoft.public.inetserver.asp.general:
Tim Slattery wrote:
How to read disabled fields at the server side


If Not isEmpty(Request.Form("max")) Then
' there was a "max" parameter in this form
Else
' there was no "max" parameter in this form
End If


That's not quite the issue, Tim. By specification, a disabled element
cannot be successful. That means no name-value pair for that element
in the request (and hence, no corresponding item in the Request.Form
collection). Absence from the request does not signify absence from
the form, however.

And indeed, he wants the value of that element. He wants it to show up
in the Request.Form collection. He just does not want to make it
convenient for the user to access that value directly.


With clientside script he could enable the element onsubmit.

Not an ASP problem though, ASP cannot help here.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
Mar 23 '06 #5

P: n/a
"Dave Anderson" <GT**********@spammotel.com> wrote:
Tim Slattery wrote:
How to read disabled fields at the server side
If Not isEmpty(Request.Form("max")) Then
' there was a "max" parameter in this form
Else
' there was no "max" parameter in this form
End If


That's not quite the issue, Tim. By specification, a disabled element cannot
be successful.


I don't know what that sentence means.
That means no name-value pair for that element in the request
(and hence, no corresponding item in the Request.Form collection).
Yes, that's what my code tests for.
Absence from the request does not signify absence from the form, however.
Huh?
And indeed, he wants the value of that element. He wants it to show up in
the Request.Form collection. He just does not want to make it convenient for
the user to access that value directly.


If it's in the Request.Form collection, then it's been sent by the
client, and therefore the user had access to it. If you have data you
want to hide from the user entirely, you have to keep it on the
server, in the session object or a database or something.

--
Tim Slattery
MS MVP(DTS)
Sl********@bls.gov
Mar 23 '06 #6

P: n/a
Tim Slattery wrote:
That's not quite the issue, Tim. By specification, a
disabled element cannot be successful.
I don't know what that sentence means.


17.13.2 Successful controls
A successful control is "valid" for submission.
Every successful control has its control name
paired with its current value as part of the
submitted form data set. A successful control
must be defined within a FORM element and must
have a control name.

However:
. Controls that are disabled cannot be successful
. If a form contains more than one submit button...

http://www.w3.org/TR/html401/interac...ssful-controls
Absence from the request does not signify absence from
the form, however.


Huh?


The form is forbidden from submitting some controls. That does not mean they
do not exist.

The form is a client-side construct. When it is submitted, an HTTP request
is sent. If the form method is POST, the HTTP request is given a POST
method, a Content-Type header of "application/x-www-form-urlencoded", a
Content-Length header and a set of name-value pairs. IIS parses the request
and builds a Request Object, which includes a Form Collection built from the
entirety of the HTTP request. When it sees the POST method, it converts
those name-value pairs into elements of the Request.Form Collection.

So the request and the form are two different things, while the Request
Object is yet a third. The form is not the Form Collection of the Request
Object.
If it's in the Request.Form collection, then it's been sent
by the client, and therefore the user had access to it.
By definition, yes.
If you have data you want to hide from the user entirely,
you have to keep it on the server, in the session object
or a database or something.


But I don't think he was trying to hide the controls from the user. He could
have used a hidden input for that. He may, for example, have a control that
is populated by script, but one that he wants the user to see. In that case,
READONLY is a more useful attribute than DISABLED.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Mar 23 '06 #7

P: n/a
Thanks folks.

W3 is right always and its drving the web protocols.

So considering that, at the end of the submit I am explicitely enabling the
required controls so that I get their values though they look disabled on
the form later.

thanks
.. Dave Anderson wrote:
Tim Slattery wrote:
That's not quite the issue, Tim. By specification, a
disabled element cannot be successful.


I don't know what that sentence means.


17.13.2 Successful controls
A successful control is "valid" for submission.
Every successful control has its control name
paired with its current value as part of the
submitted form data set. A successful control
must be defined within a FORM element and must
have a control name.

However:
. Controls that are disabled cannot be successful
. If a form contains more than one submit button...

http://www.w3.org/TR/html401/interac...ssful-controls
Absence from the request does not signify absence from
the form, however.


Huh?


The form is forbidden from submitting some controls. That does not
mean they do not exist.

The form is a client-side construct. When it is submitted, an HTTP
request is sent. If the form method is POST, the HTTP request is
given a POST method, a Content-Type header of
"application/x-www-form-urlencoded", a Content-Length header and a
set of name-value pairs. IIS parses the request and builds a Request
Object, which includes a Form Collection built from the entirety of
the HTTP request. When it sees the POST method, it converts those
name-value pairs into elements of the Request.Form Collection.
So the request and the form are two different things, while the
Request Object is yet a third. The form is not the Form Collection of
the Request Object.
If it's in the Request.Form collection, then it's been sent
by the client, and therefore the user had access to it.


By definition, yes.
If you have data you want to hide from the user entirely,
you have to keep it on the server, in the session object
or a database or something.


But I don't think he was trying to hide the controls from the user.
He could have used a hidden input for that. He may, for example, have
a control that is populated by script, but one that he wants the user
to see. In that case, READONLY is a more useful attribute than
DISABLED.

Mar 31 '06 #8

P: n/a
abcd wrote:
Thanks folks.

W3 is right always and its drving the web protocols.

So considering that, at the end of the submit I am explicitely
enabling the required controls so that I get their values though they
look disabled on the form later.


That will work, but I don't understand why you prefer that over READONLY.
Read-only controls are successful and can be programmatically manipulated.
They ARE ALREADY what you desire.

--
Dave Anderson

Unsolicited commercial email will be read at a cost of $500 per message. Use
of this email address implies consent to these terms. Please do not contact
me directly or ask me to contact you directly for assistance. If your
question is worth asking, it's worth posting.
Mar 31 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.