But why would you have to? Just pass in the SQL and the selected id:

sub make_select {
   my ($dbh, $sql, $args, $id) = @_;
   my $items = $dbh->selectall_arrayref($sql, {Slice => {}}, $args);

   for ($items) {
      $_->{selected} = 1 if $_->{id} == $id;
   }

   return $items;
}
[download]

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

well, i guess a function more like this ... passing SQL into it, would do the trick. (along with the name of the possible selected value, since in some cases it's ID, others it's NAME, etc )

something in me just says that passing around SQL is a bad idea. i don't know why... it's a gut feeling about later maintainability.

I find that this is a Very Good Idea™! Why are you so sceptical? :)

Passing the SQL around is no more or less maintainable than passing the resulting data structure around. There may be better ways ... but no way is really good unless you plan and design it ahead of time. FWIW, i think using Maypole is the real Very Good Idea™.

And yes, passing the name of the possible selected value might be a good idea ... but if you always rely on a primary key and you always call it the same (such as simply id), then you circumvent that problem. Also, if you have the id, then there is no reason to use another value for the value of your select box. Another lable, yes, but not another value. Use the id! Finally, choosing a naming scheme that allows you to program smart and conveniently is very beneficial -- allowing you to write generic and simple subroutines. Of course, if this is for EVERYONE to use, then yes ... you need to add the ability to customize it.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)