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=addPromot er", 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.

[Lasse Reichstein Nielsen]

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

Lasse Reichstein Nielsen wrote:

Thomas 'PointedEars' Lahn <Po*********@we b.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/rasterTriangleD OM.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*********@we b.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.javas cript 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.javas cript 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="submitNam e" value="Click here"
class="submitBt n" />
</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
"transparen t" 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*****@agrico reunited.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