Re: Insert into table when user clicks one of many submit buttons
by ww (Archbishop) on Nov 28, 2011 at 02:30 UTC
|
Perhaps I'm missing something in your explanation, but it sounds to me as though you are presenting buyers with a page which has multiple forms each using a submit button, one for each "track" you're offering for sale... and thinking that clicking a submit button will send anything other than what's in its form to the server. Forms, submit and communication between browser and server don't work that way.
If my surmise about your html is correct, you should review html documentation for "check boxes," which allow for multiple selections by a user ... and should also clear up what seem to be some misconceptions about how submit buttons work.
For a decent example of how this would work for you (or so it seems to me), see http://www.w3schools.com/html/tryit.asp?filename=tryhtml_form_checkbox. N.B.: I am NOT suggesting you utilize the html shown there but rather, saying that the code and the demonstration (in the right box) should serve be cogently illustrative of a means to get multiple offerings into a single form. | [reply] |
|
|
Thank you for your reply. I am using one form with multiple submit buttons. Using check boxes is a good suggestion, but I was hoping to have the user to only have to click a buy button as opposed to checking of boxes then clicking a buy button. That is the way I see most other sites do it. Perhaps they are using javascript for this?
| [reply] |
Re: Insert into table when user clicks one of many submit buttons
by aaron_baugher (Curate) on Nov 28, 2011 at 03:30 UTC
|
You'll have to show us your form HTML to get more than a guess, but here's one: do your hidden fields have the same name attribute, like this?
<input type='hidden' name='cat_num' value='track1' />
.....
<input type='hidden' name='cat_num' value='track2' />
If that's the case, the browser may send the first value, or the last one, or do something random. I'm not sure the behavior is defined in the case of multiple input fields having the same name, but I am sure that's not going to work very well.
There are a couple of different ways to fix that, but first I'd look at what you're trying to do. Presumably you want to know which track(s) the user has selected. If you only want one track selected at a time, you can get rid of the hidden fields and give each submit button a different name, like "submit_track1", and parse that key to find out which one was clicked. If you want to allow multiple tracks to be checked, you'll need to put checkboxes next to them, or something that lets the user select a quantity. In that case, you would put the track name in the checkbox or other input field, and again would not need the hidden field. In fact, it's hard to see how hidden fields would help you here, since you need to use fields the user can interact with, to tell you which track(s) he wants.
| [reply] [d/l] |
|
|
| [reply] |
|
|
Thanks for the correction. I reckoned that's how it worked, since other field types work that way; but I didn't take the time to look it up because it wouldn't have solved his problem. Treating it as an array would give him the values of all his hidden fields instead of only the first one, but that still wouldn't tell him which item(s) was selected. I should have mentioned it, though.
| [reply] |
|
|
| [reply] |
|
|
[same name attribute] the browser may send the first value, or the last one, or do something random.
I believe the standard says that they shall send them all. (This is at least the situation with checkboxes.) CGI.pm can then return those values as an array.
| [reply] |
Re: Insert into table when user clicks one of many submit buttons
by tinita (Parson) on Nov 28, 2011 at 11:30 UTC
|
$row = $form{id};
my $insert=qq~ insert into cart (id,cat_num) select id,catalog_num fro
+m tracks where id ='$row'~;
sql injection alert!
please read http://bobby-tables.com/
| [reply] [d/l] |
Re: Insert into table when user clicks one of many submit buttons
by locked_user sundialsvc4 (Abbot) on Nov 28, 2011 at 03:04 UTC
|
Indeed... if your page consists of multiple <form>s, only one of those forms will be submitted. Therefore, your multi-line catalog form needs to be just one form, with un-ambiguous names for each submitted variable.
I often find it convenient to use an HTTP “session” to good advantage here, storing everything that I need to know about each item that I’m presenting within the session, along with some arbitrary-but-random string which is what I actually include in the various generated form-variable names. (This lets me identify what the user has referred-to, without actually trusting any of the values he’s submitted.)
| |
Re: Insert into table when user clicks one of many submit buttons
by locked_user sundialsvc4 (Abbot) on Nov 28, 2011 at 12:30 UTC
|
An HTML <form>, no matter what it “looks like” to the end-user, ultimately consists of a whole bunch of <input> tags of various kinds (including “hidden” and “button”). Each <input> has a name that you give it, and a value that the user enters. When the user hits any of the buttons in the form, the browser assembles a bunch of name=value pairs and submits them to wherever the form says they should all go.
What your Perl program receives, then, is a bunch of those pairs. Make of them whatever you can. You do this by encoding information somehow into the name and using it to understand the value.
The trick is, though ... (“Bobby Tables”) ... you must not trust anything that the browser sends you. In particular, you must not merely “incorporate it, verbatim, into an SQL command.”
A web browser always assumes that you are right. If you are not right (i.e. mal-formed HTML...), the browser either ignores you or it “makes do with what it’s got.” HTML, also, is very generous. You can have a bunch of buttons in the same form, all with the same name and value.
By far the easiest way to sort these things out is to use a browser-side debugger like Firebug. This lets you conveniently s-e-e exactly what the host is sending, and exactly what the browser is sending back.
| |