Request.form("max")

[abcd]

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

[Dave Anderson]

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.

[Tim Slattery]

"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

[Dave Anderson]

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.

[Evertjan.]

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)

[Tim Slattery]

"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

[Dave Anderson]

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.

[abcd]

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.

[Dave Anderson]

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.