469,343 Members | 5,279 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,343 developers. It's quick & easy.

Javascript submit() function

So.. I have a form that submits to an ASP.net site made in C-sharp.
The ASP site is not mine, i do not have the server side code.

When I submit from my form by pressing the Submit button, I get
different results than when I use a javascript submit: form1.submit();.
I think the javascript submit is working as it should, since I want
the server to process an __EVENTTARGET posting. When I click the
submit button, it does not process the __EVENTTARGET field. However,
it should really work the same way whether i click a button or whether
javascript submits, right? Why is there a difference? I used firefox
to see what fields were being posted to the server, and the POSTFields,
referrer, etc. all are identical.

Oh, btw, when I use libcurl to post the same fields, it does not
process the __EVENTTARGET either, as if I had clicked the submit button.

May 17 '06 #1
10 5712
ljlolel said the following on 5/17/2006 7:10 PM:
So.. I have a form that submits to an ASP.net site made in C-sharp.
The ASP site is not mine, i do not have the server side code.
Irrelevant to client side Javascript.
When I submit from my form by pressing the Submit button, I get
different results than when I use a javascript submit: form1.submit();.
Then the form may have an onsubmit event handler that changes the form's
contents.
I think the javascript submit is working as it should, since I want
the server to process an __EVENTTARGET posting. When I click the
submit button, it does not process the __EVENTTARGET field. However,
it should really work the same way whether i click a button or whether
javascript submits, right?
No.
Why is there a difference?
Because they are submitted using different methods.
I used firefox to see what fields were being posted to the server, and the POSTFields,
referrer, etc. all are identical.

Oh, btw, when I use libcurl to post the same fields, it does not
process the __EVENTTARGET either, as if I had clicked the submit button.


Not sure what libcurl is.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
May 17 '06 #2
ljlolel wrote:
So.. I have a form that submits to an ASP.net site made in
C-sharp. The ASP site is not mine, i do not have the server
side code.

When I submit from my form by pressing the Submit button,
I get different results than when I use a javascript submit:
form1.submit();. I think the javascript submit is working as
it should, since I want the server to process an __EVENTTARGET
posting. When I click the submit button, it does not process
the __EVENTTARGET field. However, it should really work the
same way whether i click a button or whether javascript
submits, right?
When a form is submitted using a submit button a name/value pair for the
submit button used is sent with the request. If you use the - submit -
method of the form no submit button qualifies as 'successful' and no
name/value pair is sent. However, competent server-side script authors
will determine some default action to handle circumstances where the user
submits a form without using a submit button (browsers provide varied
mechanisms for doing so, including keyboard shortcuts).
Why is there a difference? I used firefox
to see what fields were being posted to the server,
and the POSTFields, referrer, etc. all are identical.

<snip>
Are they?

In any event, if this is not intended to be cross-browser you could
attempt to call the - click - method of the pertinent submit button to
submit the form (that would not be cross-browser because not all browsers
implement a - click - method on their submit buttons).

Richard.
May 17 '06 #3
There is no onsubmit event handler. To simplify everything, I wrote a
10-line form to submit to the server. When I click the submit button,
it doesn't register __EVENTTARGET. When i uncomment the submit()
function in the javascript, it does register this input and returns the
appropriate results.

I know this sounds really weird, and I wouldn't believe it if I hadn't
done it several times myself. I dont understand how there can be a
difference. Firefox lists all of the fields posted, and they are
identical whichever way I submit. The same inputs should yield the
same outputs, but for some reason something is very wrong.

May 18 '06 #4
Nevermind. Telling you is too hard and I sound crazy (I definetely
think I must be going nuts). Here is a link to my form:
http://perla.princeton.edu/counselors/organization.php . It posts an
action to nacacnet.org.

Now, look at the code. No onsubmits, just a couple of necessary hidden
inputs. Now, if you click on the submit button, it takes you to
results 1-15, the first page, of the list of organizations. But, if
you run the submit() function through javascript, it goes to page 6
(which it should). Look at firefox's page info... it sends the same
info... but gets different results. If you solve this conundrum, you
should write the next da vinci code book ;-).

May 18 '06 #5
jo*********@gmail.com a écrit :
think I must be going nuts). Here is a link to my form:
http://perla.princeton.edu/counselors/organization.php

Now, look at the code. No onsubmits, just a couple of necessary hidden
inputs.


I've looked through the "code", i think you should start cleaning all
the HTML mess (missing tags, tags not allowed into another, missing
attributs, bad content-type, etc.) before thinking about getting
something reliable from javascript ! I'm gonna cut/paste some of the
markup, but around 10/15 HTML problems or warning in a 15 lines
document, i think it's too much.

Your page is served as text/html, so there is no need for the /> that's
can be seen everywhere on your page. Anyway, let's assume it's a quick
and dirty cut/paste from a real XHTML page but if so, the test page is
not acurate to the issue you encounter in real world. Sometimes the
javascript behavior is slightly different in HTML and XHTML. Is your
page HTML or XHTML ?

No doctype, that's a bad practice, please choose one.

<html>
<form method="post" name="MemberDirectory" id="MemberDirectory"
action="http://...Directory/?NRMODE=Published&amp;...">

Here the method is post but the action is looking like a get request. I
dont think it's clever to mix post and get requests. I bet the problem
you encounter is comming from this.

[snip]

</form>
<input type="submit" onclick="javascript:notfirstpage();" />

Again, no need for the /> if it's not a XHTML document.
Input tag outside a form ? The structure of a HTML document does not
allow to insert all type of tags in all conditions.
onclick="javascript: ... " is totally wrong, please just use
onclick="return my_function();"

And why use a submit type ? Don't you just want a button ?

<script language="JavaScript">

If you are reading this newsgroup you should know by now this is the
crappiest way to insert a script. It's useless to use the language
attribute and the type attribute is required.
You should instead use <script type="text/javascript">

function notfirstpage()
{
form1 = document.forms["MemberDirectory"];
form1.submit();
}

Perhaps it would be wise to read the newsgroup before asking, or at
least read documentations.

when you do

form1 = document.forms["MemberDirectory"];

the variable "form1" is created in the global scope, you want here to
use a local variable, so you must use : var

var form1 = document.forms["MemberDirectory"];

Since notfirstpage() is the onclick handler, you must return true or
false to abort or keep running the event.

Anyway, imo the problem is inside the confusion between post method and
get url of the form's action.

--
laurent
May 18 '06 #6
laurent,
I coded this in a couple of minutes by hand, for the sole purpose of
showing this weird problem. I've moved to xhtml 1.0 transitional, even
though that matters not at all for a test page.

Your suggestion that it was a problem with the action url seemed like a
good one. Unfortunately, I just changed it, and it still doesn't work
:(. I still don't know what could possibly be the problem.
http://perla.princeton.edu/counselors/organization.php
j

May 18 '06 #7
Laurent Vilday wrote:
[...]
[snip]

</form>
<input type="submit" onclick="javascript:notfirstpage();" />

Again, no need for the /> if it's not a XHTML document.
Input tag outside a form ? The structure of a HTML document does not
allow to insert all type of tags in all conditions.
Input elements can appear outside forms, however to use a type submit
outside a form doesn't make any sense. Maybe the button is outside the
form and using script to call the form's submit method in a lame attempt
to force the user to have JavaScript enabled or to try and force the
submit handler to run - neither outcome can be guaranteed and in both
cases an input type button would be more suitable.

The button should be inside the form and the onclick function should be
added to the form's onsubmit handler.

If the OP wants a reference to the submit button passed to the server,
give the button a name (anything other than 'submit'):

<form id="MemberDirectory" onsubmit="notfirstpage();" ...>
...
<input type="submit" name="MemberDirectorySubmitButton">
</form>

Usually the function called onsubmit returns true or false, then the
handler returns whatever the function returns so that form submission
can be canceled by the function.

onclick="javascript: ... " is totally wrong, please just use
onclick="return my_function();"
Don't use either, put the function on the form's submit handler.

[...]
function notfirstpage()
{
form1 = document.forms["MemberDirectory"];
form1.submit();
}
[...]
the variable "form1" is created in the global scope, you want here to
use a local variable, so you must use : var

var form1 = document.forms["MemberDirectory"];
If it was necessary at all, then:

document.forms["MemberDirectory"].submit();

seems better, no variable needed.

Since notfirstpage() is the onclick handler, you must return true or
false to abort or keep running the event.


No, it doesn't. If the button is outside the form, once the form's
submit() method is called, that's it. The function can then do what it
wants, it can no longer influence submission (maybe it could try to
interrupt submission by changing location.href or something silly but
that is unlikely to be robust).

If the function is put on the form's submit handler, it can stop
submission provided JavaScript is available, the function returns
-false- and the submit handler pass the returned value to the form, e.g.

<form ... onsubmit="return someFn();" ...>

Now if someFn returns false, it will be passed to the form and
submission will be stopped. However, if the onsubmit handler doesn't
pass on the value:

<form ... onsubmit="someFn();" ...>

someFn can return whatever it likes, the form will be submitted.
--
Rob
Group FAQ: <URL:http://www.jibbering.com/faq/>
May 18 '06 #8
Laurent Vilday <mo****@mokhet.com> writes:
</form>
<input type="submit" onclick="javascript:notfirstpage();" />


This looks fragile.

The onclick event calls a method that calls submit. Then the
event ends without cancelling the default behavior, and the
form is potentially submitted again.

Maybe a browser will stop after the first submit, but then again,
it might use the last navigation instead (I know that sometimes
after I press a link, but before the page is unloaded, I change
my mind and press another link ... and that works). You just
can't know for sure, so you should make sure exactly one of those
are possible.

So change this to:
<input type="submit" onclick="notfirstpage();return false;" value="..">
or even better:
<input type="button" onclick="notfirstpage();" value="..">

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
May 18 '06 #9
RobG wrote:
<form id="MemberDirectory" onsubmit="notfirstpage();" ...>
...
<input type="submit" name="MemberDirectorySubmitButton">
</form>

Usually the function called onsubmit returns true or false, then the
handler returns whatever the function returns so that form submission
can be canceled by the function.
No, it does not do that automatically. You have to write

<form ... onsubmit="return notfirstpage();" ...>

for that, as you explained below. It is also a Good Thing if the validating
function is passed `this', the reference to the DOM object representing the
`form' element, in order to access the form controls' value. Probably the
`form' element does not need an ID then anymore, as the required reference
is already there.
[snipped explanation on how to cancel the submit event]

PointedEars
--
Multiple exclamation marks are a sure sign of a diseased mind.
-- Terry Pratchett
May 23 '06 #10
jo*********@gmail.com wrote:
There is no onsubmit event handler.


Yes, there is. Your problem is that you do not make use of it,
and that you do not quote a bit of what you are replying to.
PointedEars
--
In the First World War, 13 million people were killed. In the Second
World War, 40 million people were killed. I think that if a third war
takes place, nothing is going to be left on the face of earth.
-- Shakira, 2003-02-05 @ MTV.com
May 23 '06 #11

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Xeon | last post: by
2 posts views Thread by Margaret Werdermann | last post: by
4 posts views Thread by javascript_noob12 | last post: by
1 post views Thread by michael.friis | last post: by
1 post views Thread by winstontuck | last post: by
5 posts views Thread by Rabel | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
1 post views Thread by Marylou17 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.