Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP General > Request.form("max")

Reply
Thread Tools

Request.form("max")

 
 
abcd
Guest
Posts: n/a
 
      03-22-2006
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


 
Reply With Quote
 
 
 
 
Dave Anderson
Guest
Posts: n/a
 
      03-22-2006
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.


 
Reply With Quote
 
 
 
 
Tim Slattery
Guest
Posts: n/a
 
      03-23-2006
"abcd" <(E-Mail Removed)> 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)
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Dave Anderson
Guest
Posts: n/a
 
      03-23-2006
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.


 
Reply With Quote
 
Evertjan.
Guest
Posts: n/a
 
      03-23-2006
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)
 
Reply With Quote
 
Tim Slattery
Guest
Posts: n/a
 
      03-23-2006
"Dave Anderson" <(E-Mail Removed)> 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)
(E-Mail Removed)
 
Reply With Quote
 
Dave Anderson
Guest
Posts: n/a
 
      03-23-2006
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.


 
Reply With Quote
 
abcd
Guest
Posts: n/a
 
      03-31-2006
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.



 
Reply With Quote
 
Dave Anderson
Guest
Posts: n/a
 
      03-31-2006
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.


 
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




Advertisments