Wiggins d'Anconia wrote:
Andrew Gaffney wrote:
I have a Perl CGI script that runs a query against a MySQL table. I have about 20 boolean values that I want shown as checkboxes in the produced HTML, but I don't want to have to do something like the below for every value.
The key to this is contriving good names for the check boxes, usually such that they can be looped over...
That's not an option. The values have been defined months and months ago and are hard-coded in a number of places.
Ah the power of poor planning....
[code] if($ref->{somevalue}) { print "<input type=checkbox name=somevalue value=1 checked>"; } else { print "<input type=checkbox name=somevalue value=1>"; } [/code]
foreach my $index (1 .. 20) {
print "<input type=checkbox name=somevalue$index " . ($ref->{"somevalue$index"} ? ' checked=checked' : '') . ">";
}
The (exp ? string : string) is called the ternary operator, perldoc perlop for more.
Will this work in a here doc?
Don't know... god I hate here docs... give it a shot but I doubt it.
Converting back is easy enough:
[code] use CGI; my $cgi = new CGI; my $p = $cgi->Params;
$somevalue = $p->{somevalue} or $somevalue = 0; [/code]
If it was checked, it will be passed along with a value of 1. If it's not checked, it won't be passed along and will return undef if I try to grab it from the $p hash. Although, how could I quickly convert all the values back for something like:
[code]
$dbh->do("UPDATE table SET somevalue1='$p->{somevalue1}', somevalue2='$p->{somevalue2}', somevalue3='$p->{somevalue3}', somevalue4='$p->{somevalue4}', somevalue5='$p->{somevalue5}', somevalue6='$p->{somevalue6}'");
[/code]
Generally what I do is break up the statement, so
my @bind; my $set = ''; foreach my $index (1 .. 20) { if (defined $p->{"somevalue$index"}) { $set .= ', ' if ($set ne ''); $set .= '?'; push @bind, $p->{"somevalue$index"}; } }
Won't work in my case due to the already defined field names.
Theoretically the looping construct should still work, but rather than creating a list based on an incrementing index just create an array and step through the elements of the array... If that isn't possible then likely you need to rethink your design and refactor a lot or grunt it out and the next time you have a chance to re-examine the whole structure do so.... Sometimes the simplest (and only) solution is to copy and paste, granted that usually indicates a lack of upfront planning or a mindset where the system is evolving constantly isn't taken (read: eXtreme Programming or the like).
my $st = "UPDATE table SET $set";
Now you have constructed your update statement, pass it and the bind variables to a prepare/execute ('do' might work too) but binding variables works really well here (and for any other fields that may need to be apostrophe escaped, etc.).
Would MySQL choke if it was expecting a non-null integer value for all of those? If so, how can I handle that without a lot of code? I currently handle the data both ways by having a textfield with a '1' or '0' in the generated HTML, but it looks ugly.
Depends on the table definition. If you have fields marked as NOT NULL then it might since it won't like NULL values, though empty strings are not NULLs. Alternatively set a default value in the table definition, for instance I use 0 for off usually, anything that I am not checking NULLs against I automatically have initialized to 0.
I am not entirely sure I understood what you are after, if this didn't get it please clarify and I (we) will see what we can come up with...
At first glance, as long as the ternary operator works in a here doc, displaying the HTML will work. I already have all of the boolean values set as NOT NULL with a default value of '0' so I shouldn't have to do anything extra to put them back in if they're not checked.
Alternatively you could use an HTML parser to look for the input fields, then adjust the values of the fields while looping over your template, rather than dropping a bunch of ternaries (plural?) into a here doc, but I suspect you won't like that suggestion either, though it has worked very well in the past for me, and means I only need one form parsing routine and some template files rather than a bunch of HTML hardcoded into a heredoc.....
to each their own....
http://danconia.org
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
