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.

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)

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.

well, that's part of the issue. the database is inconsistent, and without spending a week trying to graft a better solution onto a third-party datasource *and* a 'legacy' MySQL system, i'm stuck passing the key field name.

and i don't know why i disagree with passing SQL statements around ... it just ... i dunno ... seems to me like it starts to turn into an unmaintainable spaghetti monster. sure, i'll be able to debug it tomorrow, but what about the next guy, or even me 6 months from now ( w/out looking at the code, i might as well be 'that new guy' ).

Have you even tried it yet? Look ... like i said before, whether you pass the SQL around or you pass the resulting data structure around ... it's all going to be spaghetti code unless you take care for it not to be. Here were i work, we use something like this to create a select box:

my $fields = [ qw(id name) ];
my $table  = $dbh->selectall_arrayref('
   select id, name from some_table
');

my $select = $self->select_prep($fields, $table, $selected_id); 

# now "send" $select to HTML::Template
[download]

select_prep takes a 2 dimensional array and returns a datastructure suitable for HTML::Template.

However, i have had much maintainability success by using Class::Phrasebook::SQL in some of my past personal projects. I store the SQL queries in an XML file that is parsed into a hash. The user passes in the key as a query parameter:

# param might contain go_director=42 (id for the director)
# or maybe go_genre=72 or go_writer=150

if (my ($choice) = grep /^go_/, param()) {
    my $query = $BOOK->get($choice);
    print make_table($dbh, $query, param($choice));
}
[download]

Where make_table is a thin wrapper for my DBIx::XHTML_Table module, which takes a SQL query string and returns the results already wrapped in an XHTML table. Here is an entry from the XML Phrasebook:

<phrase name="go_director">
    select movie.id,movie.title,movie.year,movie.id as img
    from movie inner join director_xref on movie.id=director_xref.movi
+e_id
    inner join director on director_xref.director_id = director.id
    where director.id= ?
    order by movie.year
</phrase>
[download]

The SQL is tucked away in an XML file (i can pretend they are stored procedures ;)) and my code is free of SQL. What's not maintainable about that? Now, my design of what i do with the SQL could be improved, but that's my doing ... not the technique itself.

Why are we having this conversation ... go ... experiment! Try new things. Even if your gut tells you it won't work, it's all good experience. :)

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)