processing a form

[teddy.am]

I know this is stupid,
but i've been trying to process a form while adding a function to the
onClick event.

as soon as i add the onClick event, the function is triggerred but the
form doesn't POST or GET.

Any help?

[Erwin Moller]

te******@gmail.com wrote:

I know this is stupid,
but i've been trying to process a form while adding a function to the
onClick event.

as soon as i add the onClick event, the function is triggerred but the
form doesn't POST or GET.

Any help?

Hi,

If you use the submitbutton, you can go 2 ways:
1) Use type="button" instead of type="submit"
Add an onClick handler that also submits the form.

eg:
<form action="bla.php" name="myForm">
firstname: <input type="text" name="firstname">
<input type="button" value="submit now" onClick="checkform();">
</form>

<script type="text/javascript">
function checkform(){
// do something here
....
// submit it
document.forms.myForm.submit();
}
</script>
As you can see, this solution is a little unfriendly for people with
Javascript disabled because they will not submit the form because
Javascript is responsible for the submitting.

If that is unacceptable for you, have a look at the second solution:

2) use onSubmit() handler in the submit-button-element.

<form action="bla.php" name="myForm">
firstname: <input type="text" name="firstname">
<input type="submit" value="submit now" onSubmit="checkform();">
</form>

In this case the form will ALWAYS be submitted if javascript is disabled.
If Javascript is ENABLED the function checkform() can return true or false.
Retrun false to prevent submitting.

Regards,
Erwin Moller

[teddy.am]

Thanks,

it worked.
Also one more problem,

i used this:
<input type="button" name="Submit" value="Send" onclick="this.disabled
= true;">

and after clicking, the button was disabled successfully.

I tried to make a function that disables the button, but it didn't
work.
why?

[RobG]

Erwin Moller wrote:
[...]

If you use the submitbutton, you can go 2 ways:
1) Use type="button" instead of type="submit"
Add an onClick handler that also submits the form.
[...]
As you can see, this solution is a little unfriendly for people with
Javascript disabled because they will not submit the form because
Javascript is responsible for the submitting.
It is also unpleasant because even if scripting is enabled, if the
script fails for any reason, the form will not submit.

If that is unacceptable for you, have a look at the second solution:

2) use onSubmit() handler in the submit-button-element.

That is the preferred method - scripting should always be helpful and
never a hindrance.

[...]

--
Rob

[teddy.am]

the onSubmit="" thingy didn't work with me.
does it need a specific html or js version to work?

[RobG]

te******@gmail.com wrote:

the onSubmit="" thingy didn't work with me.
does it need a specific html or js version to work?

Please quote what you are replying to. Since you seem to be using the
Google groups interface, don't use the stock 'reply' link below the
message. Click on the options link and then use the reply link that
appears - it will quote the message for you.

The onsubmit handler must be on the form, not the input element:

<form .... onsubmit="return someFunction();">
...
</form>
someFunction() does whatever it does. If it returns false, submit is
canceled. If true (or just nothing), then the form submits.
--
Rob

[Erwin Moller]

RobG wrote:

Erwin Moller wrote:
[...]

If you use the submitbutton, you can go 2 ways:
1) Use type="button" instead of type="submit"
Add an onClick handler that also submits the form.
[...]

As you can see, this solution is a little unfriendly for people with
Javascript disabled because they will not submit the form because
Javascript is responsible for the submitting.

It is also unpleasant because even if scripting is enabled, if the
script fails for any reason, the form will not submit.

Well, that depends on the quality of the Javascripter, right?
;-)

If that is unacceptable for you, have a look at the second solution:

2) use onSubmit() handler in the submit-button-element.

That is the preferred method - scripting should always be helpful and
never a hindrance.

Yes, that is reasonable advise, but I think it depends on the situation if
it is always true.

I heard that statement too many times. I think it is a dogma. (Nothing
personal)
The reason I say that is simply that I often develop webapps for intranets
where I know what to expect (javascriptwise and browserwise).

In such cases it is no problem to expect Javascript to be enabled, and makes
the coding a lot more easy, and the use of the webapp a lot more friendly.
(A lot of functionality cannot be made otherwise, and, if you must, require
a fresh page created by the server with some scriptinglanguage to mimic
Javascripts functionality. That is slow and gives poor interactivity
compared to JS.)

If you develop for the world at large: you are right: In such cases it is
more friendly to use JS only for additional friendlyness, not as a
requirement.

But still, even on the web with all the different visitors/browsers, I have
no problem with an webapp that expects Javascript to be enabled. A lot of
pages expect me to have Flash/Java/Shockwave/etc, so what is so strange to
expect Javascript to be enabled?
Every browser I know of has JS build in these days.

So, for me, it depends on the situation.
I also made websites for the whole internet that expect you to have JS
enabled. (Of course I will tell the visitor that instead of silent
failing.)
IMHO JS is so mainstream that if a visitor disables it, or uses a browser
that does not support it, that same visitor should not be surprised to have
problems with some pages.
I expect a browser to understand basic CCS too.
And frames (alltough I don't use them)
And images.
etc.

I know a lot of people think otherwise, but this is my opinion.
Go with the flow: this is 2005, why disable Javascript and complain certain
things don't work?
I don't see the point in all the extra work that has to be done to
circumvent a disabled JS, and I am not talking about submitting a form
alone here.
Look at dynamic texts, smarts forms that display only relevant parts, etc.
Javascript is a real asset here.

(I do not want to start a flamewar, but just want to state another opinion
on this matter.)

Regards,
Erwin Moller

[Erwin Moller]

te******@gmail.com wrote:

the onSubmit="" thingy didn't work with me.
does it need a specific html or js version to work?

Show us some code. :-)

Regards,
Erwin Moller

[teddy.am]

<script language="javascript">
function myFunction() {
this.form1.submit.disabled = true;
}
</script>
<input type="submit" name="submit" value="Send"
onSubmit="myFunction();">

as simple as that.
I want the submit button to disable as soon as the user clicks it,
avoiding the click more than once.

[Erwin Moller]

te******@gmail.com wrote:

<script language="javascript">
function myFunction() {
this.form1.submit.disabled = true;
}
</script>
<input type="submit" name="submit" value="Send"
onSubmit="myFunction();">

as simple as that.
I want the submit button to disable as soon as the user clicks it,
avoiding the click more than once.

Hi,

Rob showed you the trick already. :-)
Use 'return' in the onSubmit-handler, like this:
onSubmit="return somefunction();"

So somefunction() returns true or false, false meaning NOT to submit.
You have to add that to your function.

Also the use of the word 'this' is not good in your context, I think.
('this' is typically used to point to the object, which method is invoked.)

Just use document.forms.formnamehere.submit.disabled = true;

Replace formnamehere with the actualy formname.

And are you sure that a double click on the button submits the form again?
If so, than this an usefull addition, but I never observed that behaviour.
(Could very be happening nonetheless. :P)

Good luck.

Regards,
Erwin Moller

[RobG]

Erwin Moller wrote:

RobG wrote:

Erwin Moller wrote:
[...]

If you use the submitbutton, you can go 2 ways:
1) Use type="button" instead of type="submit"
Add an onClick handler that also submits the form.

[...]

As you can see, this solution is a little unfriendly for people with
Javascript disabled because they will not submit the form because
Javascript is responsible for the submitting.

It is also unpleasant because even if scripting is enabled, if the
script fails for any reason, the form will not submit.

Well, that depends on the quality of the Javascripter, right?
;-)

If that is unacceptable for you, have a look at the second solution:

2) use onSubmit() handler in the submit-button-element.

That is the preferred method - scripting should always be helpful and
never a hindrance.

Yes, that is reasonable advise, but I think it depends on the situation if
it is always true.

It's reasonable, sensible advice that is applicable to any programming
situation.

I heard that statement too many times. I think it is a dogma. (Nothing
personal)
The reason I say that is simply that I often develop webapps for intranets
where I know what to expect (javascriptwise and browserwise).
That is a different argument. The particular issue here is using an
input button with an onclick handler rather than an input submit and
an onsubmit handler on the form.

In many browsers, regardless of whether the form has a submit button,
the form will be submitted if a control is in focus and the user
presses the enter key. If the in-focus control is not the faux submit
button, the button's onclick event is completely bypassed. That will
happen for onclick events on submit buttons too.

If your server is not setup to accept data that has not been
pre-processed by the client-side script, who knows what may happen?
Robust programming is all about handling the 0.01% of cases that are
exceptions, the 99.99% is the easy bit.

In such cases it is no problem to expect Javascript to be enabled, and makes
the coding a lot more easy, and the use of the webapp a lot more friendly.
(A lot of functionality cannot be made otherwise, and, if you must, require
a fresh page created by the server with some scriptinglanguage to mimic
Javascripts functionality. That is slow and gives poor interactivity
compared to JS.)
Server-side stuff does not have to mimic the client-side, only provide
a functional site.

The biggest issue is replacing standard UI behaviour with coded
behaviour. Browsers are good a some things and pretty rotten at
others. Users readily accept standard behaviours, even expect it:
programmers need to extend and enhance them, not try to replace them.
Script and DOM simply don't give you enough control to roll your own.

[...] I don't see the point in all the extra work that has to be done to
circumvent a disabled JS, and I am not talking about submitting a form
alone here.
Look at dynamic texts, smarts forms that display only relevant parts, etc.
Javascript is a real asset here.
Yes, but that kind of stuff falls in the realm of minor enhancements
that, if they don't work, are but a minor hindrance (provided things
aren't hidden by HTML and require script to reveal). The page can
still be fully functional without script, even if more difficult to use.

One reason for ensuring that everything still works sans scripting is
that it helps protect against malicious users, who can appear on
intranets just as often as in the wild.

It also helps protect against changes to your computing platform over
which you may not have any control (the changes, that is).

(I do not want to start a flamewar, but just want to state another opinion
on this matter.)

No problem, these issues need to be discussed sensibly from time to time.
--
Rob

[Lee]

Erwin Moller said:

RobG wrote:

It is also unpleasant because even if scripting is enabled, if the
script fails for any reason, the form will not submit.

Well, that depends on the quality of the Javascripter, right?

Not entirely. It also depends on whether the user decides to upgrade
his browser to a version that doesn't work quite the same. Being on
an Intranet does not necessarily protect you from that. Sooner or
later your users will upgrade, and you might not even be around when
it happens.

That is the preferred method - scripting should always be helpful and
never a hindrance.

Yes, that is reasonable advise, but I think it depends on the situation if
it is always true.

I heard that statement too many times. I think it is a dogma.

Can you provide an example in which scripting should be a hindrance
instead of helpful?

[Erwin Moller]

Lee wrote:

Erwin Moller said:

RobG wrote:

It is also unpleasant because even if scripting is enabled, if the
script fails for any reason, the form will not submit.

Well, that depends on the quality of the Javascripter, right?

Hi Lee,

Thanks for your response.
Not entirely. It also depends on whether the user decides to upgrade
his browser to a version that doesn't work quite the same. Being on
an Intranet does not necessarily protect you from that. Sooner or
later your users will upgrade, and you might not even be around when
it happens.
That is true.
However, usage of stringlength, access to values of formelements, etc, tend
to stay the same, especially when you use oldfashioned approach like
document.forms.name.value.

It is true I expect that to keep working for futher versions of JS.
But I could as easily throw your own argument back at you: How do you know
that next version of IE will support forms anyway? But you use them
nonetheless.
You see what I mean?
I just think it is reasonable to expect certain behaviour to stay the same.

That is the preferred method - scripting should always be helpful and
never a hindrance.

Yes, that is reasonable advise, but I think it depends on the situation if
it is always true.

I heard that statement too many times. I think it is a dogma.

Can you provide an example in which scripting should be a hindrance
instead of helpful?

You are a funny guy Lee. :-)
You are right of course. Touche.
Lee-Erwin: 1-0 on logic. :-)

Of course I didn't want to defend that a hindrance is better than helpfull.
I was merely stating that it is not completely crazy to make an app that
expects JS to be enabled...
But you knew that he?
;-)

Regards,
Erwin Moller

[Erwin Moller]

RobG wrote:

Hi Rob,

Thanks for your reply.
This is an important discussion and I am glad your throw some solid
arguments at my head.
Some I agree with, some I don't. Well read on. :-)

<snip>

I heard that statement too many times. I think it is a dogma. (Nothing
personal)
The reason I say that is simply that I often develop webapps for
intranets where I know what to expect (javascriptwise and browserwise).
That is a different argument. The particular issue here is using an
input button with an onclick handler rather than an input submit and
an onsubmit handler on the form.

In many browsers, regardless of whether the form has a submit button,
the form will be submitted if a control is in focus and the user
presses the enter key. If the in-focus control is not the faux submit
button, the button's onclick event is completely bypassed. That will
happen for onclick events on submit buttons too.

Good point.
I completely admit onClick is a bad solution compared to onSubmit.
I'll never use it again in that context.
(Not sarcastic, you are just right.)

If your server is not setup to accept data that has not been
pre-processed by the client-side script, who knows what may happen?
The receiving script should check forms anyway IMHO.
All my receiving scripts expect a hacker, and treat the posted data that
way.
Robust programming is all about handling the 0.01% of cases that are
exceptions, the 99.99% is the easy bit.
true.

In such cases it is no problem to expect Javascript to be enabled, and
makes the coding a lot more easy, and the use of the webapp a lot more
friendly. (A lot of functionality cannot be made otherwise, and, if you
must, require a fresh page created by the server with some
scriptinglanguage to mimic Javascripts functionality. That is slow and
gives poor interactivity compared to JS.)
Server-side stuff does not have to mimic the client-side, only provide
a functional site.

Well, that sounds great in theory, but in real life you have different
situations.
Consider this: A huge form that contains a fault?
A normal serverside solution would be to present the form again to the
client, and if you are being friendly you also provide it with the values
the user used the first time, and hightlight the bit that contains a fault.

That is a lot of work, and all the more when the form is complex.
Think about multiple selectboxes, radiobuttons, etc.
I did implement such solutions various times. It is a lot of work.

In such cases JS really makes the life of the programmer and the visitor a
lot more comfortable.
JS tells what is wrong, so the visitor do not have to type in in again, or
the programmer should provide all the values again.

The biggest issue is replacing standard UI behaviour with coded
behaviour. Browsers are good a some things and pretty rotten at
others. Users readily accept standard behaviours, even expect it:
programmers need to extend and enhance them, not try to replace them.
Script and DOM simply don't give you enough control to roll your own.

[...]

I don't see the point in all the extra work that has to be done to
circumvent a disabled JS, and I am not talking about submitting a form
alone here.
Look at dynamic texts, smarts forms that display only relevant parts,
etc. Javascript is a real asset here.
Yes, but that kind of stuff falls in the realm of minor enhancements
that, if they don't work, are but a minor hindrance (provided things
aren't hidden by HTML and require script to reveal). The page can
still be fully functional without script, even if more difficult to use.

Yes, i know.
But my customers demand sexy, quick behaviour in their browser, and I
comply.
I even think they are right in demanding that.

One reason for ensuring that everything still works sans scripting is
that it helps protect against malicious users, who can appear on
intranets just as often as in the wild.
Sure. That is why receiving scripts should always expect the worst.
I code accordingly. :-)

It also helps protect against changes to your computing platform over
which you may not have any control (the changes, that is).
Well..
If I use JS to simple stuff, like checking if elements have a (valid) value
and such, I EXPECT that work on the next browser that claims to support
javascript.
You expect your forms to work in the next browser too...

(I do not want to start a flamewar, but just want to state another
opinion on this matter.)

No problem, these issues need to be discussed sensibly from time to time.

Good. :-)

Thanks for your input Rob.

Regards,
Erwin Moller