Submit form with link

[Terence Parker]

Hello,

I wish to submit a form with a link instead of a submit button - but there's
a catch : using the same form, I want to have different links that submit
that form to different locations. Here's a simplification of what I have so
far:

<form name="SubmitUsers" method="POST" action="process.php">
<input type="checkbox" name="username[]" value="Some value">
<input type="checkbox" ........... >
</form>

<a href="javascript: void(0);" onclick="document.SubmitUsers.submit();return
false;">

- this link above will submit the form, but it will submit the form to
"process.php" as defined in the initial <form> clause. What if I want
another link that, say, submits to "process2.php" instead? But I want to be
able to use the same checkboxes, so I don't want to have to redefine another
form for this.

Can this be done?

Thanks!

Terence

 

[Beauregard T. Shagnasty]

Quoth the raven named Terence Parker:

I wish to submit a form with a link instead of a submit button -
but there's a catch : using the same form, I want to have different
links that submit that form to different locations. Here's a
simplification of what I have so far:

<form name="SubmitUsers" method="POST" action="process.php"> <input
type="checkbox" name="username[]" value="Some value"> <input
type="checkbox" ........... > </form>

<a href="javascript: void(0);"
onclick="document.SubmitUsers.submit();return false;">

- this link above will submit the form, but it will submit the form
to "process.php" as defined in the initial <form> clause. What if I
want another link that, say, submits to "process2.php" instead? But
I want to be able to use the same checkboxes, so I don't want to
have to redefine another form for this.

Can this be done?

Based on your description, I would add a radio button above the one
submit button, and have your process.php do what it does based on
which radio button was ticked.

Be sure to have none ticked by default.

 

[Ryan Stewart]

Hello,

I wish to submit a form with a link instead of a submit button - but there's
a catch : using the same form, I want to have different links that submit
that form to different locations. Here's a simplification of what I have so
far:

<form name="SubmitUsers" method="POST" action="process.php">
<input type="checkbox" name="username[]" value="Some value">
<input type="checkbox" ........... >
</form>

<a href="javascript: void(0);" onclick="document.SubmitUsers.submit();return
false;">

- this link above will submit the form, but it will submit the form to
"process.php" as defined in the initial <form> clause. What if I want
another link that, say, submits to "process2.php" instead? But I want to be
able to use the same checkboxes, so I don't want to have to redefine another
form for this.

Can this be done?

Thanks!

Terence

I may be wrong, but can't you change the form's action? Something like:
document.SubmitUsers.action="process2.php";

That's just a wild guess, so you'll have to do some research, but I think
it's possible.

 

[brucie]

in post: <

I wish to submit a form with a link instead of a submit button

not a good idea.

- but there's a catch : using the same form, I want to have different
links that submit that form to different locations.

use two submit buttons, script redirects based on submit button pressed.

<a href="javascript: void(0);" onclick="document.SubmitUsers.submit();return
false;">

that not going to do anything for people without JS

 

[Ryan Stewart]

in post: <

not a good idea.


use two submit buttons, script redirects based on submit button pressed.


that not going to do anything for people without JS

Well, some people think buttons are ugly and program for the vast majority
of people who have scripting enabled. And some people are assured of a user
base with scripting enabled.

 

[brucie]

in post: <

Well, some people think buttons are ugly

use css to style the button to look like a text link, its simple. (i
don't recommended it). scripting support not required.

and program for the vast majority of people who have scripting
enabled.

you're an idiot. it simply doesn't make sense to implement a solution
that will break for some people when there is a solution that will work
for everyone.

 

[Mark Parnell]

Well, some people think buttons are ugly

Whether they are ugly or not, at least your users know what they are.

and program for the vast majority of people who have scripting enabled.

Majority, yes. Vast majority? That's debatable. Most estimates say that
around 15% (that's 1 in 20) of your site's visitors will have scripting
disabled. That's a pretty significant portion, IMHO.

And why do something that requires client-side scripting when it can be
done just as easily without needing client-side scripting?

And some people are assured of a user base with scripting enabled.

Then they specify that in their original post. The OP did not, so as per
the FAQ, we assume they are talking in a www context.

 

[brucie]

in post: <

Well, some people think buttons are ugly

perhaps you could identify for me which is the text link that requires
JS to work and which is the submit button that doesn't need anything to
work in this image:

http://moreshit.bruciesusenetshit.info/submit01.png [1k]

 

[Ryan Stewart]

in post: <

Well, some people think buttons are ugly

perhaps you could identify for me which is the text link that requires
JS to work and which is the submit button that doesn't need anything to
work in this image:

http://moreshit.bruciesusenetshit.info/submit01.png [1k]

The top one is the button.

Sorry, I've gotta get used to the fact that this NG doesn't tell people what
they ask, but what they should do instead. I agree that a button is a better
solution to his problem. I also think you could be less inflammatory about
such things, as you are a good source of information in this group, but
c'est la vie.

 

[rf]

Well, some people think buttons are ugly

The "vast majority" of viewers think that buttons are just fine. They are
used to them and used to clicking on them.

Make a button look like something else and they will probably not click on
it and declare the site broken.

This is how a standard gui works. It contains, amongst other things,
familiar buttons.

Cheers
Richard.

 

[Toby A Inkster]

Majority, yes. Vast majority? That's debatable. Most estimates say that
around 15% (that's 1 in 20) of your site's visitors will have scripting
disabled.

Did you fail Maths at school? 15% is closer to one in seven.


Then include the proper button in the HTML, but use Javascript to hide it.
That way, non-Javascript users can still see and use the button.

 

[Whitecrest]

Well, some people think buttons are ugly and program for the vast majority
of people who have scripting enabled. And some people are assured of a user
base with scripting enabled.

At the very least, you can guess that it will work on 85% of your
visitors, and if it is a product or site where you probably would not go
while surfing at work (where some companies, though I never worked for
one, might turn javascript off) then that percentage would improve even
more because you have removed business surfers from the pool of possible
visitors.

Decisions decisions. Will making Javascript a requirement, actually
increase the number of people that use your site because you can now
present it to the user the way they want to see it, but you may make it
so a few of them can't see it.

So is it better to loose 15% because they can not see it (actually less
because some people will turn it on to use your site), or possibly loose
up to 85% because they don't like the way you have to present your
content just to please the 15%.

This is the decision you have to make. I personally choose to please
the 85%. Remember, no one will ever turn off Javascript when they come
to your site, but if they need the content they may will turn it on.
Even our local zealots admit to turning it on when they need to.

 

[Mark Parnell]

Did you fail Maths at school? 15% is closer to one in seven.

You're right of course. I didn't fail Maths (actually I did very well),
but evidently it has been too long.