Re: [htmltmpl] Select/option How to set "selected"?

[Puneet K. <pk...@ei...>]

On May 4, 2004, at 12:43 AM, Sam Tregar wrote:

> On Mon, 3 May 2004, Mark Fuller wrote:
>
>> ..
>
> Because CGI.pm already has it nailed.  Why reinvent the wheel?  And
> you can't beat the simplicity:
>
>   $template->param(year_select =>
>                    scalar $query->popup_menu(-name => 'year',
>                                              -values => [ 1970 .. 2020 
> ])
>                   );
>
> And in the template:
>
>   <tmpl_var year_select>
>
> I've been doing it for years now and it's never done me wrong.
>

since there are more than three ways to do it, I am actually going to 
dissent here. Personally, I don't like CGI.pm. I think it weighs a lot, 
and most of the time I use it (and I do), it mainly to extract the 
params. I am stuck with it in a recent project because I am using 
CGI::Session, and I am not sure if that will work with CGI::Simple (can 
anyone tell me if it will and how?). Talking about reinventing the 
wheel -- that is precisely what CGI.pm is trying to do... there is a 
perfectly well established HTML language there... why put it through 
another translotor.

Why don't I like CGI.pm... it is about a few thousand lines of code for 
about 2 or 3 things I want to do with it. I certainly don't want to use 
it to code HTML because that is just one more syntax to learn. I 
already know HTML however kludgy it might be. Besides, that is what my 
designer gals and guys are going to know. They will have no idea what 
the heck $query->popup_menu(-name => 'year', -values => [ 1970 .. 2020 
]) means. CGI.pm was invented to allow Perl programmers to do HTML 
without having to re-learn HTML. Since I already know HTML, but don't 
know CGI.pm, why learn CGI.pm.

I disagree with Matthew's suggestion as well (kinda rebellious here, 
no).

> Except that you have now tied your SQL statement directly to HTML 
> syntax; in which case... what is the point of using H::T -> you could 
> generate HTML output faster if you created an SQL statement which 
> generated HTML directly.
>
> The purpose of H::T is to decopule the data from the presentation.

There is always some disadvantage to any kind of abstraction. The 
purpose of H-T for _me_ is to decouple HTML and JavaScript from 
everything else. I know Perl and SQL (well, I just confessed above that 
I also know HTML, but let's overlook that). I want to separate that 
from a as-much-pure-HTML-as-possible website. Now, within my code how 
much I abstract is up to me. I could hide all the SQL by creating views 
and storedprocs for every conceivable SQL action and then just calling 
a simple SELECT statement all the time, or I could stick as much SQL in 
my Perl code and make my code db-independent (which also is not 
possible most of the time). The thing is, I can choose the level of 
abstraction that I am comfortable with. H-T has done its job 
magnificently by allowing the designers (or myself) to just concentrate 
on how it looks once there are no more syntax or logic errors.

As Jason summarized, use SQL and db to their fullest advantage, not 
just as dump respositories of data... there is much one can do with 
SQL.... use it and the db's inherent power. That coupled with 
fetchall_arrayref({}) -- yes, that is what I use almost 100% of the 
time... seems like it was tailor-made for H::T -- and you've got sweet 
code.

That said, keep in mind, in my very first response to Mark I started 
with "there are many ways of accomplishing this... here is how I would 
do it".

;-)