onClick submitForm()

[Erik]

I need to submit a form using a hyperlink, and I need to pass a
variable associated with that hyperlink.

Example: I have a page where employees enter event information, and
they are supplied a dropdown box to pick the promoter for that event.
If the promoter does not exist in the database, they need to add
him/her to the database so that the promoter can be associated with
the event. If the promoter does not exist, I want to provide a link
(Add Promoter), that will submit the form, and pass a variable to the
query page, either in the form scope or url scope, that is
"mode=addPromoter", so that I can take them immediately send them to
the promoters page, and then I will take them back to the event page
to fill in the rest of the information.

So, in a nutshell, I need to submit a form using a hyperlink, and to
also pass a variable in either the url scope or form scope.

Any help is greatly appreciated.

[Thomas 'PointedEars' Lahn]

Erik wrote:

I need to submit a form using a hyperlink, and I need to pass a
variable associated with that hyperlink.
You don't need to and you don't want to.
Example: I have a page where employees enter event information, and
they are supplied a dropdown box to pick the promoter for that event.
If the promoter does not exist in the database, they need to add
him/her to the database so that the promoter can be associated with
the event. If the promoter does not exist, I want to provide a link
(Add Promoter), that will submit the form, and pass a variable to the
query page, either in the form scope or url scope, that is
"mode=addPromoter", so that I can take them immediately send them to
the promoters page, and then I will take them back to the event page
to fill in the rest of the information.

A submit button with another `name' and/or `value' attribute
value than the default submit button will serve that purpose
and won't require neither support of client-side JavaScript
nor unreliable and time-consuming changes to the `action'
value of the form.
PointedEars

[Erik H]

I understand that possibility, but I need to use a hyperlink.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Thomas 'PointedEars' Lahn]

Erik H wrote:

I understand that possibility, but I need to use a hyperlink.

You may want to explain why you think a hyperlink is necessary.
FWIW, here you are:

<a
href="javascript:doSomethingWithTheActionAttribute (...);document.forms[...].submit();"
onclick="doSomethingWithTheActionAttribute(...);
document.forms[...].submit(); return false;">Submit</a>

will also serve the purpose if client-side JavaScript is supported
and the `action' attribute of the `form' element can be manipulated
by assigning values to a property of the respective DOM object and
submitting forms by scripts is allowed.

The doSomethingWithTheActionAttribute(...) function is up to you,
however, depending on the values the resource specified with the
`action' attribute expects.
PointedEars

[Lasse Reichstein Nielsen]

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

<a
href="javascript:doSomethingWithTheActionAttribute (...);document.forms[...].submit();"
onclick="doSomethingWithTheActionAttribute(...);
document.forms[...].submit(); return false;">Submit</a>

There is no need to have a javascript:-URI in the href. If the browser
supports javascript, then the onclick will work. If not, the href
won't work either. That is, there is almost never any need for a
javascript:-URI.

It is better to let the href point to an HTML page that makes sense.
Either a page that works without the javascript, or that lets the
server perform the action that the client-side javascript couldn't,
or just a link to a page that explains that this page needs javascript.

/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.'

[Erik]

The reason for using a hyperlink is aesthetics. Using a button would
definitely be simple, I use that for this type situation in other places,
but here I want/need to use something small, so either an image or a
hyperlink would work best.

My javascript abilities are still novice, so I'm a little lost with what
you suggested. My basic experience tells me that I can use
<a href="#" onclick="submitForm()">Add Promoter</a>, and then create a
function that will in turn submit the form, and at the same time pass the
variable of 'mode=addPromoter'. I am using ColdFusion, so I can pass the
variable in either the form or url scope.

Also, what I can use here will work when the user needs to edit the
promoter, so I can pass 'mode=editPromoter' on a different page.

[Thomas 'PointedEars' Lahn]

Lasse Reichstein Nielsen wrote:

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

<a
href="javascript:doSomethingWithTheActionAttribute (...);document.forms[...].submit();"
onclick="doSomethingWithTheActionAttribute(...);
document.forms[...].submit(); return false;">Submit</a>
There is no need to have a javascript:-URI in the href.

But there is.
If the browser
supports javascript, then the onclick will work. If not, the href
won't work either. That is, there is almost never any need for a
javascript:-URI.
Please note that event handlers are standardized, `javascript:' URIs are
not. The latter is `common practice' anyway, so the above combination has
a 100% chance to work if client-side JavaScript is supported and enabled.
It is better to let the href point to an HTML page that makes sense.
Either a page that works without the javascript, or that lets the
server perform the action that the client-side javascript couldn't,
You forgot that the form data to be submitted is then lost, so the
Good Thing you are suggesting and I generally agree with is AFAIS
not applicable here.

If you want people without JavaScript to submit forms, use form buttons
in the first place. If you don't like their look, use CSS to format them,
or use <input type="image" ...> for submit buttons (but note that Netscape
4.x users are then excluded.)
or just a link to a page that explains that this page needs javascript.

Doing that is the best way to piss off users. The better way is to write
that hyperlink dynamically using DOM scripting, document.write(...) or
HTMLElement.appendChild(...), respectively.

And the best way is to discard hyperlinks for form operation, use
server-side scripting where possible, and use client-side scripting
if it reduces traffic (ref.: form validation.)
PointedEars

[Lasse Reichstein Nielsen]

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

Lasse Reichstein Nielsen wrote:

If the browser supports javascript, then the onclick will work. If
not, the href won't work either. That is, there is almost never
any need for a javascript:-URI.

Please note that event handlers are standardized, `javascript:' URIs are
not. The latter is `common practice' anyway, so the above combination has
a 100% chance to work if client-side JavaScript is supported and enabled.

Do you know of *one* browser where the javascript:-URI works and the
onclick attribute doesn't? If there isn't one, there is no need for
the URI, since it will only ever be used by non-javascript browsers.
You forgot that the form data to be submitted is then lost, so the
Good Thing you are suggesting and I generally agree with is AFAIS
not applicable here.
That is a point. If there is another way to submit the form when
Javascript is off, then clicking the link can be a problem. The
javascript:-URI doesn't appear to do anything with Javascript off.
If you want people without JavaScript to submit forms, use form buttons
in the first place.
If you want people *with* Javascript to submit forms, use form buttons
anyway. That is what the user expects.

If a form uses a link instead of a submit button, I would easily be
confuzed about how to submit it.

or just a link to a page that explains that this page needs javascript.

Doing that is the best way to piss off users.

Is it so much better than making a page that fails completely if
Javascript is disabled? At least this way, the user will know what
went wrong.

However, I must admit that when I suggest such a link, it is partly
because I want the try to write the explanation for why his site cannot
work without Javascript. It can be an eye opener.
The better way is to write that hyperlink dynamically using DOM
scripting, document.write(...) or HTMLElement.appendChild(...),
respectively.
That is a solution. If the link is vital to the page, the entire
page can be written that way.
And the best way is to discard hyperlinks for form operation,
Definitly!
use server-side scripting where possible, and use client-side
scripting if it reduces traffic (ref.: form validation.)

Yep,
/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.'

[Thomas 'PointedEars' Lahn]

Erik wrote:

The reason for using a hyperlink is aesthetics.
You should learn that esthetics must always be implemented
in a way that does not oppose usability to be successful.
Using a button would definitely be simple, I use that for this type
situation in other places, but here I want/need to use something small,
so either an image or a hyperlink would work best.
What is it that you don't like `<input type="image" ...>'?
My javascript abilities are still novice, so I'm a little lost with what
you suggested. My basic experience tells me that I can use
<a href="#" onclick="submitForm()">Add Promoter</a>, and then create a
function that will in turn submit the form, and at the same time pass the
variable of 'mode=addPromoter'.
No, the user-defined submitForm() method must change the `action'
property of the DOM form object and *then* call its submit() method:

function submitForm(oForm)
{
if (oForm && typeof oForm.action != "undefined" && oForm.submit)
{
oForm.action = "foobar";
oForm.submit();
}

return false;
}

<a
href="javascript:submitForm(document.forms[...])"
onclick="return submitForm(document.forms[...]);">Submit</a>
I am using ColdFusion, so I can pass the
variable in either the form or url scope.
You could also manipulate the `value' property of a DOM `input'
object and then call the submit() method of the form object:

function submitForm(oForm)
{
if (oForm
&& oForm.elements
&& oForm.elements["foo"]
&& oForm.elements["foo"].value)
&& oForm.submit)
{
oForm.elements["foo"].value = "bar";
oForm.submit();
}

return false;
}

Maybe it is required to use the setTimeout(...) function
to wait a few (milli)seconds before submitting the form:

setTimeout('document.forms[...].submit()', 42);
Also, what I can use here will work when the user needs to edit the
promoter, so I can pass 'mode=editPromoter' on a different page.

You need to pass $promoterID to that page,
too, using one of the suggested solutions.
PointedEars

[Thomas 'PointedEars' Lahn]

Lasse Reichstein Nielsen wrote:

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

Lasse Reichstein Nielsen wrote:

> If the browser supports javascript, then the onclick will work. If
> not, the href won't work either. That is, there is almost never
> any need for a javascript:-URI.
Please note that event handlers are standardized, `javascript:' URIs are
not. The latter is `common practice' anyway, so the above combination has
a 100% chance to work if client-side JavaScript is supported and enabled.

Do you know of *one* browser where the javascript:-URI works and the
onclick attribute doesn't?

No, but that is irrelevant.
If there isn't one,
Although I (or you) don't know one, there may be one.
there is no need for the URI, since it will only ever be used by
non-javascript browsers.
You don't get the point. UAs that don't know the event handler will ignore
it and access the URI, while UAs that are standards-compliant will ignore
the URI since the event is canceled with the last statement in the handler.

You forgot that the form data to be submitted is then lost, so the
Good Thing you are suggesting and I generally agree with is AFAIS
not applicable here.

That is a point. If there is another way to submit the form when
Javascript is off, then clicking the link can be a problem. The
javascript:-URI doesn't appear to do anything with Javascript off.

OK, maybe I made myself not clear enough: The hyperlink to an alternative
document that is accessed when JavaScript support is not available, is in
*this* case complete nonsense since the form data provided (namely the
promoter's name to add) is then lost.

If you want people without JavaScript to submit forms, use form buttons
in the first place.

If you want people *with* Javascript to submit forms, use form buttons
anyway. That is what the user expects.

If a form uses a link instead of a submit button, I would easily be
confuzed about how to submit it.

Full ACK.

> or just a link to a page that explains that this page needs javascript.

Doing that is the best way to piss off users.

Is it so much better than making a page that fails completely if
Javascript is disabled? At least this way, the user will know what
went wrong.

You mean they know then that the webauthor is incompetent
enough not to foresee that certain possibility. Great.
However, I must admit that when I suggest such a link, it is partly
because I want the try to write the explanation for why his site cannot
work without Javascript. It can be an eye opener.

You played the devil's advocate again? ;-)

The better way is to write that hyperlink dynamically using DOM
scripting, document.write(...) or HTMLElement.appendChild(...),
respectively.

That is a solution. If the link is vital to the page, the entire
page can be written that way.

No, that would be definitely a Bad Thing unless users without JavaScript
don't get there in the first place, i.e. it is not even listed in search
engines. But you then can disregard users without JavaScript anyway and
the time-consuming and sometimes hard-to-read DOM scripting is no longer
required.
PointedEars

[Lasse Reichstein Nielsen]

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

Lasse Reichstein Nielsen wrote:

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

Lasse Reichstein Nielsen wrote:
> If the browser supports javascript, then the onclick will work. If
> not, the href won't work either. That is, there is almost never
> any need for a javascript:-URI.

Please note that event handlers are standardized, `javascript:' URIs are
not. The latter is `common practice' anyway, so the above combination has
a 100% chance to work if client-side JavaScript is supported and enabled.
Do you know of *one* browser where the javascript:-URI works and the
onclick attribute doesn't?

No, but that is irrelevant.

If there isn't one,

Although I (or you) don't know one, there may be one.

There might also be one that requires the Javascript in the URI to be
spelled backwards. I don't think that is likely, so I don't spell my
javascript backwards. Likewise, I think it is extremely unlikely that
there is a browser that understands Javascript and javascript:-URIs,
but doesn't understand the onclick handler.

If you have nothing else to put in the HREF then (it is a good sign
you are using the wrong element, but) you might just as well put the
URI there. I would prefer a href that made just the tiniest amount
of sense when Javascript is disabled. Like a link to a page that
explains what should have happened if Javascript was enabled.

After all, the hypothetical browser that might use the URI isn't as
important a user group as the 10% without Javascript.

there is no need for the URI, since it will only ever be used by
non-javascript browsers.

You don't get the point.

Sure I do, I just disagree :)
UAs that don't know the event handler
That is: UAs that don't know HTML 4.
will ignore it and access the URI,
.... but will fail again if it doesn't understand or support
Javascript.
OK, maybe I made myself not clear enough: The hyperlink to an alternative
document that is accessed when JavaScript support is not available, is in
*this* case complete nonsense since the form data provided (namely the
promoter's name to add) is then lost.
Yes. That suggests a bad design, since the problem wouldn't be a problem if
a submit button was used.
You mean they know then that the webauthor is incompetent
enough not to foresee that certain possibility. Great.
Exactly :)
You played the devil's advocate again? ;-)

I wouldn't call it that. Just deliberatly thought provoking :)

That is a solution. If the link is vital to the page, the entire
page can be written that way.

No, that would be definitely a Bad Thing unless users without JavaScript
don't get there in the first place, i.e. it is not even listed in search
engines. But you then can disregard users without JavaScript anyway and
the time-consuming and sometimes hard-to-read DOM scripting is no longer
required.

Exactly. :) A page that doesn't work without Javascript should not be
reached unless Javascript is available.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Demo: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Erik H]

I'm happy to see you both used my question as an opportunity to argue
your beliefs in what should/should not be used in web development.

Neither one of you really answered my question, nor gave me a solid
solution to what I wanted to accomplish. Just so that you know,
although it is irrelevant, the application I have developed has close to
1000 pages of coldfusion/sql server 2000 code, both of which platforms I
could probably run circles around your knowledge. I completely control
all aspects of the environment, including the fact that we use IE 6 for
web development (which you both argued about usability). I wanted to
use a hyperlink to submit a form, and at the same time, pass a variable.
I wasn't looking for advice, I was looking for an answer. Luckily I
found the answer elsewhere, and will not be coming back here for help.

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Jim Ley]

On 31 Oct 2003 04:00:33 +0100, Lasse Reichstein Nielsen
<lr*@hotpop.com> wrote:

Thomas 'PointedEars' Lahn <Po*********@web.de> writes:

> there is no need for the URI, since it will only ever be used by
> non-javascript browsers.

You don't get the point.

The more important reason to not use javascript: is that it's
non-standard, and not even supported by as many user agents as support
onclick in A, also the failure scenarios even in script enabled pages
are severe with some browsers (such as IE) navigating the user to its
generic "page not found page".

There's also the problem of "open in new window" which is commonly
used by people on links, with the example in the thread, even in UA's
that can otherwise execute the script will result in the script
executing in the context of the new window.
Exactly. :) A page that doesn't work without Javascript should not be
reached unless Javascript is available.

Which is completely impossible to proof that it's available, so even
in such pages gross level protection (like a link which does not cause
errors, and does not do anything strange - but does not function as
expected ie loses the information from the form.)

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Jim Ley]

On 31 Oct 2003 06:01:20 GMT, Erik H <de***********@bigdummy.com>
wrote:

both of which platforms I could probably run circles around your
knowledge.
Do you really think it's likely to get your question answered quicker
if you come in and deride the knowledge of two people who have shown
they know they're javascript - I expect you could run circles around
their knowledge of some completely unrelated language to the
newsgroup, but it's neither relevant or useful.
I completely control
all aspects of the environment, including the fact that we use IE 6 for
web development (which you both argued about usability).
Good to see you have a good upgrade strategy in place for dealing with
the next version of the browser.
I wasn't looking for advice, I was looking for an answer.

Paid support forums are elsewhere, this is a newsgroup, all you get is
advice.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Grant Wagner]

Jim Ley wrote:

Exactly. :) A page that doesn't work without Javascript should not be
reached unless Javascript is available.

Which is completely impossible to proof that it's available, so even
in such pages gross level protection (like a link which does not cause
errors, and does not do anything strange - but does not function as
expected ie loses the information from the form.)

Jim.

Or simply use something like:

<style type="text/css">
input.submitBtn {
background-color: transparent;
border: none;
text-decoration: underline;
color: blue;
cursor: pointer;
cursor: hand;
}
</style>
<form>
<input type="submit" id="submitId" name="submitName" value="Click here"
class="submitBtn" />
</form>

and then you don't need to worry about whether client-side JavaScript is
enabled or not, you get the same behaviour regardless of the client-side
JavaScript capabilities of the UA.

By the way, Opera 7.21 appears to not understand "text-decoration:
underline;" nor does it understand the "cursor: " designations. Also,
Opera 7.21 does not properly render "border: none;". The last problem can
be dealt with by specifying:
"border: 0px solid transparent;" (well, actually the color doesn't
matter), but I'm not sure how standard a border-width of 0px is.

Also note that "border: 1px solid transparent;" works in all browsers
except IE6, where it appears that the "color: " bleeds through the
"transparent" border and you get a blue border 1px wide.

There are a very few minor problems with this approach, one is that the
color of the text on the button does not change to that of a followed
link, the other is that the "link" exhibits the behaviour of a button,
with the text shifting down and to the right when clicked. This may or may
not present a problem for your target audience.

Anyway, I'd probably rather live with the possibility that my button will
not *appear* exactly as I intended it on all browsers, as long as it
*functions* the way I intend on those same browsers. In other words, if
Netscape 4 users get a big ugly grey button, that's *their* problem, as
long as they can still get their information to me if they have JavaScript
disabled.

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html