using hyperlinks as submit buttons

A

Alexander Weiner

Hello,

I have several sites, that includes the forms in an <form method=post
action="...">.

It is absolutely necessary, that all the parameters are send by post and not
by get. Now I want to insert Hyperlinks <a href... in this form section. But
here I have to put the parameters in the url via get.

Is there a way to use the hyperlinks like a submit button that sends all the
elements in the form section via post? JavaScript is allowed.

Thanks for all answers.
 
D

David Dorward

Alexander said:
It is absolutely necessary, that all the parameters are send by post and not
by get. Now I want to insert Hyperlinks <a href... in this form section. But
here I have to put the parameters in the url via get.

The best solution is to forget it. Links go places. Buttons send data
places. They send a strong message to the user telling them what is
going to happen. Its poor usability if they send the wrong message.

That said, you can (eugh) use CSS to style buttons to look like links.
 
J

jojo

Alexander said:
Hello,

I have several sites, that includes the forms in an <form method=post
action="...">.

It is absolutely necessary, that all the parameters are send by post and not
by get. Now I want to insert Hyperlinks <a href... in this form section. But
here I have to put the parameters in the url via get.

Is there a way to use the hyperlinks like a submit button that sends all the
elements in the form section via post? JavaScript is allowed.

Thanks for all answers.

<script type="text/javascrit" language="javascript">
document.SomeForm.submit()
</script>
<body>
<form name="SomeForm" method="post" action="...">
..
..
..
</form>
</body>

Should work with all browsers.
 
D

David Dorward

jojo said:
<script type="text/javascrit" language="javascript">
document.SomeForm.submit()
</script>
<body>
<form name="SomeForm" method="post" action="...">
Should work with all browsers.

No it shouldn't.

In browsers that do support JavaScript, it should cause them to go "Eh?
What's this text/javascrit thing? I'll ignore that."

In browsers that support JavaScript, and have JavaScript turned on and
can recover from that error, it will cause them to go
"document.SomeForm? Nope, haven't seen a document.SomeForm yet." and
throw an error.

In browsers that don't support JavaScript, or have JavaScript turned
off, it will do nothing at all.
 
J

jojo

David said:
No it shouldn't.

In browsers that do support JavaScript, it should cause them to go "Eh?
What's this text/javascrit thing? I'll ignore that."

Just a spelling-error, of course it should be "text/javascript"
In browsers that support JavaScript, and have JavaScript turned on and
can recover from that error, it will cause them to go
"document.SomeForm? Nope, haven't seen a document.SomeForm yet." and
throw an error.

Yes, they have seen. Look at the form-tag...
And ASFAIK it is possible to call form-elements by thier name without
any "getElementById("")" or something else...

And if some Browser doesn't support that: document.forms[0].submit()
Or give the Form an ID and use document.getElementById("ID")
In browsers that don't support JavaScript, or have JavaScript turned
off, it will do nothing at all.

Yes, I know, but I think you missed the
 
A

Andy Dingley

Alexander said:
It is absolutely necessary, that all the parameters are send by post and not
by get.

Then you _must_ submit from a <form>, not an <a> link (OK, so you
could do some AJAX-like thing too)

You have three options: CSS, JavaScript or a lot of JavaScript.

For CSS you make a bog-standard <form> with a submit button on it, then
you use CSS to make it look as much like an <a> as possible. This is
the simplest and most robust.

For JavaScript then you code a HTML <a> as normal, code a <form> as
well, then you use JavaScript to trap the <a onclick=... > event and
use it to do a form submit instead. jojo had the right idea, but coded
it unworkably badly. Return false afterwards, or else the <a> will
still try and navigate somewhere. What to set the <a href=... >
attribute to depends on what you wnat to happen for non-JS users. If
you want them to be disabled safely, then use href="#". If you permit
them to submit via a GET, but at least have something still working,
then set this link in the href as normal. Returning false will guard
against double submissions.

With a whole bunch of JavaScript and AJAX, you can do it without the
extra HTML coding.
 
J

jojo

Andy Dingley said:
jojo had the right idea, but coded
it unworkably badly.

OK, you're right, seems like I haven't really thought about it before
posting it, I'm sorry. I forgot that the JS-Function has to be started
by click on an hyperlink...

This code will do it:

function SubmitForm(a){
document.forms[0].submit(); //if it is the first form in your code
return false;
}

To call the code add onclick="SubmitForm()" to your hyperlink.
Or, if it is not supposed to work for users with JavaScript disabled you
can set the href to "javascript:SubmitForm()", a Browser without
JavaScript will ignore this.
 
D

David Dorward

jojo said:
Yes, they have seen. Look at the form-tag...

The form tag that appears in the document AFTER the script has
executed?

When the script executes there is no form.
Yes, I know, but I think you missed the

The requirements allowing the use of JavaScript doesn't magically cause
all browsers to support it (nor does it make it a good idea to depend
on JavaScript).
 
J

jojo

David said:
The form tag that appears in the document AFTER the script has
executed?

When the script executes there is no form.

I'm sorry, look at my reply to Andy's message.
The requirements allowing the use of JavaScript doesn't magically cause
all browsers to support it (nor does it make it a good idea to depend
on JavaScript).

Of course it doesn't. But I interpreted this as a "I know about the
disadvantages of JavaScript and can live with it".
 
A

Andy Dingley

jojo said:
OK, you're right, seems like I haven't really thought about it before
posting it,

_Please_ learn to code with some semblance of decent style before
posting these rubbish snippets.
can set the href to "javascript:SubmitForm()",

In case you don't know already, don't ever use this
href="javascript:..." bogosity.
 
A

Alan J. Flavell

Of course it doesn't. But I interpreted this as a "I know about the
disadvantages of JavaScript and can live with it".

In a WWW context, that's not the question. It's not about whether
*you* as author can live with it, it's about whether *web users* can
live with it. The general view around here is that they can't and
won't, and shouldn't be expected to.

The relevant German office ("Bundesamt für Sicherheit in der
Informationstechnik") says this (in an English edition, since this is
a predominantly English-speaking newsgroup):

_
/
Avoid active content: Customers should always have the option of
refusing technologies or methods which can bring security problems
with them. These include active content such as JavaScript and
ActiveX. Only activate these in your web browser if you are on a
trustworthy website. As this is unlikely to be obvious to customers,
security-conscious suppliers should always offer a second channel.
For example, many animated demonstrations on websites require active
content such as JavaScript. Customers' attention should be drawn to
the fact that JavaScript needs to be activated in the browser to see
a demonstration, but that this can also be viewed without JavaScript
as a simple sequence of pictures.
\_

Seems to me to cover the most important points. See
http://www.bsi.de/english/publications/fb/F09E_Comz_en.pdf
 
A

Alan J. Flavell

Then you _must_ submit from a <form>, not an <a> link (OK, so you
could do some AJAX-like thing too)

You have three options: CSS, JavaScript or a lot of JavaScript.

For CSS you make a bog-standard <form> with a submit button on it, then
you use CSS to make it look as much like an <a> as possible. This is
the simplest and most robust.

It's also going to cause the more perceptive webnauts to "smell a rat"
and come to the conclusion that they are being defrauded. They might,
for example, suspect that the web site has been taken over by phishing
fraudsters, who are trying to submit user data without their consent.
 
J

jojo

Alan said:
In a WWW context, that's not the question. It's not about whether
*you* as author can live with it, it's about whether *web users* can
live with it. The general view around here is that they can't and
won't, and shouldn't be expected to.

The relevant German office ("Bundesamt für Sicherheit in der
Informationstechnik") says this (in an English edition, since this is
a predominantly English-speaking newsgroup):

_
/
Avoid active content: Customers should always have the option of
refusing technologies or methods which can bring security problems
with them. These include active content such as JavaScript and
ActiveX. Only activate these in your web browser if you are on a
trustworthy website. As this is unlikely to be obvious to customers,
security-conscious suppliers should always offer a second channel.
For example, many animated demonstrations on websites require active
content such as JavaScript. Customers' attention should be drawn to
the fact that JavaScript needs to be activated in the browser to see
a demonstration, but that this can also be viewed without JavaScript
as a simple sequence of pictures.
\_

Seems to me to cover the most important points. See
http://www.bsi.de/english/publications/fb/F09E_Comz_en.pdf

Thanks, but I prefer to read it in German...
Nothing really new in it, I knew it before. And I could not remember
that I advised anybody to use JS. But if Alexander asks for a solution
with JS he will get one. Whether he uses it or not is just his business.
I'm not trying to stop you advising him *not* to use it (In this subject
I have to agree, you should really not use it), I just want you to
notice that *I* didn't tell him he *should*, so don't make me
responsible if he does. I just told him how to do it if he wants to.
 
A

Alan J. Flavell

....
Thanks, but I prefer to read it in German...

Ohne Zweifel - but why should that be of concern to this newsgroup?
Nothing really new in it, I knew it before.

But it seems the original questioner maybe didn't, so your answer was
seriously defective.
And I could not remember that I advised anybody to use JS.

By handing out a proposed solution which not only *used* JS - but was
completely *dependent* on it (that's an important distinction), you
evidently failed to include important information which - you now
claim - was already known to you.

So the situation is even worse than had been depicted by Andy Dingley,
when he wrote:

| _Please_ learn to code with some semblance of decent style
| before posting these rubbish snippets.
But if Alexander asks for a solution with JS he will get one.

He certainly does run that risk, indeed.
Whether he uses it or not is just his business.

Without the relevant information which you now say that you already
had - but withheld from your answer, it's not clear how the questioner
could take a properly informed decision.
I just want you to notice that *I* didn't tell him he *should*, so
don't make me responsible if he does.

I just want you to notice that when you spell out a detailed solution,
withholding the appropriate caveats which, you now say, you were
already aware of, you *are* advocating the techniques which are used
in that solution, whether you say so directly or not.
I just told him how to do it if he wants to.

"_Please_ learn to code with some semblance of decent style before
posting these rubbish snippets."
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top