Thread: Re: [htmltmpl] Select/option How to set "selected"?
Brought to you by:
samtregar
From: Mark A. F. <mar...@ea...> - 2004-05-04 17:04:16
|
From: Sam Tregar <sa...@tr...> >I don't think this is too much code to expect people to write: > > $row{__selected__} = "selected" if $value; > >That's really all you're talking about, right? Does %row have special meaning in HTML::Template? I saw it used in another example. I don't know if I misunderstand something about this example. (How would I use $row{__selected__} after I set it?) What I was getting at is that something seems to be missing in TMPL_LOOP. There are two types of loops which are common, have a known/standard requirement (testing for "selected" or "checked" on every row), and the syntax for accomplishing this is always referred to as "ugly." If it's so common, so standard, and so ugly, why can't there be a way that H::T handles it behind the scenes? For example, what if H::T could recognize a special keyword (such as TMPL_LOOP_SELECTED and TMPL_LOOP_CHECKED) inside the TMPL_LOOP and automatically test an array of booleans with a reserved name (say, @__selected__) who's index corresponds to H::T's internal row counter. H::T could fill in the "selected" or "checked" value if all the conditions are correct. I don't understand why there's a known requirement to produce HTML like this, but it always seems to be pushed outside the domain of H::T. If it's just a matter of ugly template syntax, couldn't the syntax be simplified by being standardized as a common processing method? >Because CGI.pm already has it nailed. Why reinvent the wheel? And >you can't beat the simplicity: > > <tmpl_var year_select> Doesn't this move the HTML out of the template? If I have class attributes that may change depending on visitor preferences, now I have to maintain them in two places (in the template for everything except SELECT and RADIOBOX elements, and in my Perl code for these two)? Mark |
From: Mark A. F. <mar...@ea...> - 2004-05-04 19:01:21
|
From: Sam Tregar <sa...@tr...> >So if I wanted to have <tmpl_var selected> set when $thing->{bar} was on I'd add this to the loop body: Thanks Sam. I understand now. It's essentially the same thing Puneet suggested last night. At that point it was just a matter of whether it was better to have "<tmpl_var selected>" resolved with each iteration of the loop or to test it as a boolean and, if true emit " selected". It sounded like there wasn't much difference except it might look less messy without the test (letting it resolve with each iteration). >How would you setup @__selected__? Would it really be easier than the >single line of code shown above? Setting up my hypothetical reserved array name "@__selected__" would be the same as the single line of code you used. Just an array of 0 (or undef) or 1 indicating if the row should process my hypothetical lable "<TMPL_LOOP_CHECKED>". I was just trying to think of some way to simplify the Template syntax. Some way to move the testing for this commonly emitted string into H::T so the loop structure might look cleaner. But, it sounds like the result of this idea wouldn't look much different than just letting a TMPL_VAR resolve with each iteration. (Sorry). >You're telling me you don't keep a list of your class attributes in >your Perl code already? I don't believe you! I don't understand. I don't have any elements or attributes in my Perl code. It's all contained in templates. I feel like I'm missing a point of sarcasm? Mark |
From: Sam T. <sa...@tr...> - 2004-05-04 19:27:53
|
> >You're telling me you don't keep a list of your class attributes in > >your Perl code already? I don't believe you! > > I don't understand. I don't have any elements or attributes in my > Perl code. It's all contained in templates. I feel like I'm missing > a point of sarcasm? Nope, I just misread your comment as referring to Perl class attributes rather than CSS class attributes. You're correct that if the form elements need CSS classes then you'd need to pass them to CGI.pm in the Perl code. Although, it occurs to me that you could just tell your HTML designers to wrap the tag in a <span> and use that to apply their CSS: <span class="jazzy"><tmpl_var some_select></span> -sam |
From: Sam T. <sa...@tr...> - 2004-05-04 17:36:51
|
On Tue, 4 May 2004, Mark A. Fuller wrote: > Does %row have special meaning in HTML::Template? I saw it used in > another example. I don't know if I misunderstand something about > this example. (How would I use $row{__selected__} after I set it?) It's just a common way to setup a loop: my @loop; foreach my $thing (@things) { my %row; $row{foo} = $thing->{bar}; push(@loop, \%row); } $template->param(things => \@loop); So if I wanted to have <tmpl_var selected> set when $thing->{bar} was on I'd add this to the loop body: $row{selected} = "selected" if $thing->{bar}; > For example, what if H::T could recognize a special keyword (such as > TMPL_LOOP_SELECTED and TMPL_LOOP_CHECKED) inside the TMPL_LOOP and > automatically test an array of booleans with a reserved name (say, > @__selected__) who's index corresponds to H::T's internal row > counter. H::T could fill in the "selected" or "checked" value if all > the conditions are correct. How would you setup @__selected__? Would it really be easier than the single line of code shown above? > What I was getting at is that something seems to be missing in > TMPL_LOOP. There are two types of loops which are common, have a > known/standard requirement (testing for "selected" or "checked" on > every row), and the syntax for accomplishing this is always referred > to as "ugly." If it's so common, so standard, and so ugly, why can't > there be a way that H::T handles it behind the scenes? Actually, I find my standard way of accomplishing these things to be quite elegent. I actually like CGI.pm and I think it works very well with HTML::Template. Other people may choose to employ other solutions, but that doesn't motivate me to help them. > Doesn't this move the HTML out of the template? Sure, it's a trade-off. You gain some simplicity by setting up the <select> in your code. You lose some flexibility by not letting the HTML designer diddle a small chunk of HTML. I've found that it rarely causes problems since designers don't usually need to work on these tags. > If I have class attributes that may change depending on visitor > preferences, now I have to maintain them in two places (in the > template for everything except SELECT and RADIOBOX elements, and in > my Perl code for these two)? You're telling me you don't keep a list of your class attributes in your Perl code already? I don't believe you! -sam |