Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

does disabled JavaScript cause onSubmit to destroy hidden values?

Status
Not open for further replies.

seta

Programmer
Jan 12, 2003
5
US
After 7 hours of experimenting and reading, I'm stumped:

Here's the really short version:
If onSubmit doesn't execute because JavaScript is disabled, does its presence in the form tag somehow prevent the values in hidden input fields from being passed along via POST?

If you can answer from the above summary, you might not need the following, but here's why I ask:

I have a form where the user must answer all 12 multiple-choice questions by selecting radio buttons, or the results will not be accurate.

In the first version, I had PHP check that all questions were answered and send an error message if any were not. The only drawback was that, if the user did omit an answer, he/she would have to select all of them again. I could get around this by storing them in MySQL and building the questions dynamically, but I'd like to see if JavaScript can help out.

When I add a JavaScript validation via onSubmit, it warns the user of an omission before the page is submitted, which does the trick.

Here's the problem: If the user has JavaScript disabled, when he/she hits the SUBMIT button, not only does the JavaScript validation not occur (of course), but the backup PHP validation also gets skipped. The results page shows up without any indication of questions not answered. Those few users will get inaccurate results, which is a lot worse than having to re-select all of the buttons. (I did the JavaScript disabled test in Netscape 4.7 in Windows ME.)

I use a PHP $seeform variable to govern whether the input form or the results are displayed.

Here's the basic structure:

........................................

if ( $seeform != "no" ) {
// show questions
}

// submit questions and, if all answered, analyze

echo &quot;<FORM name=\&quot;userInfo\&quot; method=\&quot;POST\&quot; action=\&quot;$PHP_SELF\&quot; onSubmit=\&quot;return validateProfile()\&quot;>&quot;;

//when form submitted, $seeform is set to no
<INPUT type=&quot;hidden&quot; name=&quot;seeform&quot; value=&quot;no&quot;>

// JavaScript checks to see if all questions answered
function validateProfile() . . .
// if any question lacks a checked selection, stop submit
{
alert(&quot;Please make sure to answer every question.&quot;);
return false;
}
// if every question has an answer, submit allowed
return true;
}

// PHP checks to see if all questions answered
// if any missed, questions displayed with error message
if ( !$complete ) {
echo &quot;<b>Please make sure to answer [missed] questions.</b>&quot;;
$seeform = &quot;yes&quot;;
}
else
// show results

...............................

One solution I thought of was to get JavaScript to write the onSubmit part of the form tag so that, if a user was not running JavaScript, that part of the tag would not exist and thus would not cause the PHP validation to be skipped, but after many attempts, I couldn't figure out exactly how to write that JavaScript within the form tag.

Questions:

1. How might I prevent the onSubmit event in the form tag from causing the PHP validation to be skipped when the user has JavaScript disabled? This behavior surprised me. Is there some particular structure that causes this, and that I might avoid?

2. If the solution is to write the onSubmit event into the form tag using JavaScript, how might I write it?

Any suggestions would be greatly appreciated.
 
What if you tried to use the <noscript>?

I don't know PHP, so you may need to proof the server side code. (additions are in red)

echo &quot;<script language=javascript>document.write('<FORM name=\&quot;userInfo\&quot; method=\&quot;POST\&quot; action=\&quot;$PHP_SELF\&quot; onSubmit=\&quot;return validateProfile()\&quot;>')&quot;;

echo &quot;<noscript><FORM name=\&quot;userInfo\&quot; method=\&quot;POST\&quot; action=\&quot;$PHP_SELF\&quot;>&quot;;


this should cause the on submit version to be used if javascript is enabled but use the one without onsubmit if javascript is not enabled.

Don't know if it works or not but you can try and let us know.

Chris.
 
A little tinkering with the PHP var $seeform should untangle this situation. The application has three states: Ready For Input (user needs to click radio buttons); Ready For Evaluation (user had answered all 12 questions); Ready For Display (all 12 answers checked, result ready). Try something like this --

step 0. $seeform = &quot;yes&quot;

step 1. show user questions, respond to Submit. if client-side JavaScript is available test form for completeness. Show incomplete responses a message and stay here. If complete, change $seeform to &quot;no&quot; and pass control back to server Evaluate script. Of course, if client-side JavaScript is not available control passes to server Evaluate script, $seeform is still &quot;yes&quot;.

step 2. server Evaluate script checks $seeform. if still &quot;yes&quot;, client was unable to check for completeness (JavaScript disabled), server must do checking and bounce incomplete forms back to step 1. Otherwise --

step 3. check answers and display result.

The difference is the initial value of $seeform. Make the default value &quot;invalid&quot;, use client-side JavaScript to change if appropriate. This way if the client is unable to field test the form the server side processes will know.
 
Thanks, Topher0303 and Wray, for your quick and helpful responses. I lucked into a couple of extra days to experiment with this. I'll try your ideas and report back.
 
Results:

topher0303: Your idea seemed great, but the server still doesn't get the message to execute the PHP check.

wray: I haven't been able to get your suggestion to work, either, but I'm not sure I really understand how it would circumvent the problem.

Thanks again, both of you, for your suggestions.

I ended up writing the whole thing in PHP, including having PHP store previous answers in MySQL. It was quite a lot of work for one form, but I'm at home with PHP.

I'm still curious to understand what was going on with the JavaScript attempt. What puzzles me most about this whole thing is how the presence of the onSubmit tag is altering the hidden form values when JavaScript is disabled. I'd be interested in any further thoughts.

 
$PHP_SELF is not clear for me. What is the benefit of using the same script for entry, validation, and reporting?

Factoring the problem into three scripts seems natural:

Script 1 (executes at client): display questions and accept responses. If JavaScript is available, field test responses staying at client until requirements met -- exit to Script 3 when okay. If no JavaScript exit to Script 2.

Script 2 (executes at server): test responses for validity. If not valid, build Script 1 (modified for available responses) and pass it to client. Otherwise --

Script 3: use responses to build results page and pass it to client.

The complexity of managing all possible problem states while bouncing to and from server/client invites confusion. Self reference via $PHP_SELF doesn't make anything any easier.

My comments about $seeform are based on this --

>> I use a PHP $seeform variable to govern whether the input form or the results are displayed.

more than on the code snippets (which use $complete for control as well). To my eye this is more likely a problem with the server-side control mechanism than a bug in the HTML Submit POST processes.
 
Thanks, Wray, for your further ideas.

The main advantage to $PHP_SELF in this case is that, when the user omits an answer, the error message appears just above the form. The alternative would be having the error message on its own page, then going back to the previous page, or recreating the form on the second page, which wouldn't be a big deal, using an include(), but is a little less efficient. $PHP_SELF shouldn't complicate matters much, but I'll experiment with using separate pages to see whether it helps.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top