Thread: [htmltmpl] A valid reason for template support for select lists?
Brought to you by:
samtregar
Menu
▾
▴
html-template-users
|
From: Mark F. <mar...@ea...> - 2003-10-19 20:03:57
|
I just found html::template and it's exactly what I was looking for. The only thing that is a minor shortcoming for me is the inability to do option select lists. I understand the emphasis on keeping a template a template (and languages separate). But, here's an example of why I believe it is justifiable to provide for an "if" inside the variable loop that would emit an option list. The reason I like template is that I would like to serve relatively static pages, many with forms, localized to languages. I'd like to have an "en" directory for English pages, "es" for Spanish, etc. Static content can be translated and maintained in those directories. A script can display the correct language depending on a visitor's language preference. I don't see any other tools that make it as *easy* to do this as template does. But, let's say a page will have a form and in that form will be a select list. Let's say the list is "sex" and the choice is male or female. Across all the localized pages I intend to use value "1" and "2", but I want the displayed text to localized (example: "Hombre" or "Mujer" if the templates in the "es" directory are being processed.) I believe, to accomplish this I must create a MySQL table named "sexes" and maintain the relationship between "1" and "2", the language codes, and the values for the language. Then, in my script I would select the words to display in the select list and output the entire select list as a variable to be replaced in the template. That's not a showstopper for me. It's a valid way to do it too. My only point is, I don't believe I should have to go through the overhead of selecting static language-dependent values from a table when I'd be perfectly happy hard-coding them in the language-specific instances of the template. They aren't going to change. But, I have to have some way to set "selected" depending on whether the value is "1" or "2" (my language independent enumeration). I believe this is a valid case where the absense of an if requires me to move template-type information (static) somewhere else. The only thing that changes is the choice value. Am I on the right track if I use template::expr inside an options list and test at each option to know if I should emit the selected attribute? Anyway, it's a terrific tool. I just wanted to say that it seems like there's valid uses for some logic in the template and it shouldn't be disparaged the way a lot of the documentation seems to. (Just my 2-cents. I love the tool, really!). Thanks, Mark |
|
From: Sam T. <sa...@tr...> - 2003-10-19 21:34:54
|
On Sun, 19 Oct 2003, Mark Fuller wrote: > I just found html::template and it's exactly what I was looking for. The > only thing that is a minor shortcoming for me is the inability to do option > select lists. I understand the emphasis on keeping a template a template > (and languages separate). But, here's an example of why I believe it is > justifiable to provide for an "if" inside the variable loop that would emit > an option list. Are you saying you can't do this now? I've produced <select> boxes with HTML::Template. It requires a nasty pile of <tmpl_if> logic but it's doable. My prefered method is to just use CGI.pm's popup_menu() and use it to fill a single <tmpl_var>. I find this results in easily maintainable code with the minor caveat that the HTML designer won't be able to easily modify the contents of the <select>. In practice this isn't much of a problem; the contents of form controls are usually my job. > Am I on the right track if I use template::expr inside an options list and > test at each option to know if I should emit the selected attribute? Sure, that's another way to do it. -sam |
|
From: Mark F. <mar...@ea...> - 2003-10-19 23:04:25
|
> From: "Sam Tregar" <sa...@tr...> > Are you saying you can't do this now? I've produced <select> boxes > with HTML::Template. It requires a nasty pile of <tmpl_if> logic but > it's doable. Hi Sam. Yes, I think "tmpl_if" will work. The problem I have is that my templates will be organized by spoken language. The english ones in a "en" directory. Spanish in "es" directory. My script will determine which templates to access depending on the visitor's language preference. Now, in a template I might have an option box for "male or female". In Spanish, "hombre or mujer." This language difference is kept in the template, and an ordinal is used to communicate to the scripts what the choice was. Regardless of language, "1" is a male, and "2" is a female. So, in this case, it would defeat the strength of templates to call some other device to emit the option box. I'd have to store the language text in a MySQL table and pass it to the device that will create the option box. I'd rather not do that since the text logically belongs in the template instance for that language. So, yes, I could set a param name for "one" and "two" and "three". Which ever is set to boolean true, that would be the option line to get the "selected" attribute. But, that seems like a difficult way to do it. The conditional test for string value (in template::expression) would be easier. I could set a single param to "two" and in the template test for "one" or "two" or "three". One param name with different values. It just seemed like template::expression gave me *a lot* more things which, at this point, I agree are undesireable. Now that I think about it, I believe I could set a param name for "one" and "two" and "three" but instead of making them true and false (and using an if statement) I could set the correct one to "selected" and just let each variable be replaced by its value. Only one would have "selected" and it would be emitted at the correct option line. Do you know if it would be more efficient to set one var and use a conditional to determine which option select line to treat differently. Or, set many vars and let them all be replaced (to null except one). Thanks, Mark |
|
From: Sam T. <sa...@tr...> - 2003-10-19 23:22:25
|
On Sun, 19 Oct 2003, Mark Fuller wrote:
> Now, in a template I might have an option box for "male or female". In
> Spanish, "hombre or mujer." This language difference is kept in the
> template, and an ordinal is used to communicate to the scripts what the
> choice was. Regardless of language, "1" is a male, and "2" is a female. So,
> in this case, it would defeat the strength of templates to call some other
> device to emit the option box. I'd have to store the language text in a
> MySQL table and pass it to the device that will create the option box. I'd
> rather not do that since the text logically belongs in the template instance
> for that language.
Sounds like a compelling case for building the <select> in the
template. Either that or you need to go to some kind of gettext-style
i18n database. You might need that anyway, for error messages and
other generated text.
> Now that I think about it, I believe I could set a param name for "one" and
> "two" and "three" but instead of making them true and false (and using an if
> statement) I could set the correct one to "selected" and just let each
> variable be replaced by its value. Only one would have "selected" and it
> would be emitted at the correct option line.
That works. Something like:
<option value="foo" <tmpl_if foo_selected>selected</tmpl_if>>Foo</option>
<option value="bar" <tmpl_if bar_selected>selected</tmpl_if>>Bar</option>
Then you just set one "${name}_selected" to 1.
> Do you know if it would be more efficient to set one var and use a
> conditional to determine which option select line to treat differently. Or,
> set many vars and let them all be replaced (to null except one).
If you can avoid using HTML::Template::Expr then you should. It's
much slower than HTML::Template and uses more memory. But if you have
to use it anyway then it won't matter much which path you choose.
If you're worried, try both and let Benchmark.pm decide!
-sam
|
|
From: Mark F. <mar...@ea...> - 2003-10-20 02:53:05
|
>From: "Sam Tregar" <sa...@tr...> > > ... or you need to go to some kind of gettext-style > i18n database. You might need that anyway, for error messages and > other generated text. I wasn't familiar with that. I've been out reading anything I can find in search results and I think you're right. I thought templates would be an efficient way to maintain different languages served by CGIs. I'm sorry if I'm straying from the charter of this mailing list. But, Do you know of any tutorials, books or how-tos explaining the use of gettext in CGIs? For example, are the different locale headings determined automatically by the server (from something the browser sends reflecting the user's settings?) Or, is it customary to ask the user and do gettext based upon their answer? Thanks! Mark |
|
From: Sam T. <sa...@tr...> - 2003-10-20 03:32:20
|
On Sun, 19 Oct 2003, Mark Fuller wrote: > Do you know of any tutorials, books or how-tos explaining the use of gettext > in CGIs? For example, are the different locale headings determined > automatically by the server (from something the browser sends reflecting the > user's settings?) Or, is it customary to ask the user and do gettext based > upon their answer? Sorry, I don't. Here's what I'd do if I needed to find out: 1) Search on search.cpan.org. Possible terms: gettext, i18n, locale. 2) Post on perlmonks.org. It's a great place for just about any Perl question and I'm sure there's a few i18n gurus hanging around. -sam |
|
From: Mark F. <mar...@ea...> - 2003-10-22 03:04:24
|
>From: "Sam Tregar" <sa...@tr...> > > Or, is it customary to ask the user and do gettext based > > upon their answer? > > Sorry, I don't. Here's what I'd do if I needed to find out: I did a lot of searching and reading. I think HTML::Template can be useful when serving multi-lingual pages that are relatively static. For something more dynamic, maybe due to changing error messages. I found that there is a Perl module Locale::Maketext[1] which does what "gettext"[2] while providing some interesting flexibility. For example, let's say I want to return "0 entries found," "1 entry found," or "2 entries found." With gettext I would have to have two lexicon elements to accomodate negative, singular and plural forms. I would not include the number with the text, therefore the number would always be emitted to the left regardless of language. (Other languages may be more natural to say "found 0 entries".) Locale::Maketext lets you specify numbers as parameters to the lexicon. It also has a method to determine negative, singular or plural and use the correct word in the lexicon. Also, being written in Perl, I suppose it could be used with mod-perl and made persistent. (Not sure). Anyway, I hope I didn't stray too far off-topic with this feedback. I think it could be useful to HTML::Template users because the resulting text from a Locale::Maketext call could be substituted into a templates. This way templates can be more easily used for multi-lingual purposes. Additionally, I also learned it's better to ask the visitor which language they prefer (rather than using the http header value). But, the http header value can be used to make a best-guess about the language to use to ask them which language they prefer. Also learned that UTF-8 encoding should be used regardless of the language unless it is found there is not enough support for the language, at which time you should maintain an association between language codes and more specific character sets for the specific language. [1] http://search.cpan.org/~sburke/Locale-Maketext-1.06/lib/Locale/Maketext.pod [2] http://www.gnu.org/software/gettext/gettext.html For why gettext is limited, read this amusing story: http://search.cpan.org/~sburke/Locale-Maketext-1.06/lib/Locale/Maketext/TPJ13.pod Thanks! Mark |
|
From: simran <sim...@re...> - 2003-10-20 03:31:28
|
Have a look at the HTML::FillInForm module as well, i use it quite a lot in conjunction with HTML::Template to have the right "select fields" selected - works like a charm. On Mon, 2003-10-20 at 07:31, Mark Fuller wrote: > > From: "Sam Tregar" <sa...@tr...> > > Are you saying you can't do this now? I've produced <select> boxes > > with HTML::Template. It requires a nasty pile of <tmpl_if> logic but > > it's doable. > > Hi Sam. Yes, I think "tmpl_if" will work. The problem I have is that my > templates will be organized by spoken language. The english ones in a "en" > directory. Spanish in "es" directory. My script will determine which > templates to access depending on the visitor's language preference. > > Now, in a template I might have an option box for "male or female". In > Spanish, "hombre or mujer." This language difference is kept in the > template, and an ordinal is used to communicate to the scripts what the > choice was. Regardless of language, "1" is a male, and "2" is a female. So, > in this case, it would defeat the strength of templates to call some other > device to emit the option box. I'd have to store the language text in a > MySQL table and pass it to the device that will create the option box. I'd > rather not do that since the text logically belongs in the template instance > for that language. > > So, yes, I could set a param name for "one" and "two" and "three". Which > ever is set to boolean true, that would be the option line to get the > "selected" attribute. But, that seems like a difficult way to do it. The > conditional test for string value (in template::expression) would be easier. > I could set a single param to "two" and in the template test for "one" or > "two" or "three". One param name with different values. It just seemed like > template::expression gave me *a lot* more things which, at this point, I > agree are undesireable. > > Now that I think about it, I believe I could set a param name for "one" and > "two" and "three" but instead of making them true and false (and using an if > statement) I could set the correct one to "selected" and just let each > variable be replaced by its value. Only one would have "selected" and it > would be emitted at the correct option line. > > Do you know if it would be more efficient to set one var and use a > conditional to determine which option select line to treat differently. Or, > set many vars and let them all be replaced (to null except one). > > Thanks, > Mark > > > > ------------------------------------------------------- > This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo > The Event For Linux Datacenter Solutions & Strategies in The Enterprise > Linux in the Boardroom; in the Front Office; & in the Server Room > http://www.enterpriselinuxforum.com > _______________________________________________ > Html-template-users mailing list > Htm...@li... > https://lists.sourceforge.net/lists/listinfo/html-template-users |
|
From: Cees H. <ce...@si...> - 2003-10-20 03:56:56
|
Perhaps you are looking at the wrong tool to solve this problem. Personally I
never use TMPL_VARs to fill out my forms. I use HTML::FillInForm to do it for
me. This would solve your problem and simplify your templates (no need for the
tmpl_if mess to select an option in a selection box). With HTML::FillInForm you
just create your select list statically in the template (or dynamically with
HTML::Template if you want). Then once you get your $template->output, send it
to HTML::FillInForm and pass it either a hash of the form field values or just
pass the CGI query object, and it will parse your HTML and fill out the form for
you.
This adds an extra step in your code, and will impact performance since
HTML::FillInForm has to parse the HTML to fill in the form, but in most of my
apps this is acceptable. A simple example follows:
my $query = new CGI;
my $template = new HTML::Template(...);
my $fif = new HTML::FillInForm;
my $html = $fif->fill(scalarref => \$template->output(),
fobject => $query);
Cheers,
Cees
Quoting Mark Fuller <mar...@ea...>:
> > From: "Sam Tregar" <sa...@tr...>
> > Are you saying you can't do this now? I've produced <select> boxes
> > with HTML::Template. It requires a nasty pile of <tmpl_if> logic but
> > it's doable.
>
> Hi Sam. Yes, I think "tmpl_if" will work. The problem I have is that my
> templates will be organized by spoken language. The english ones in a "en"
> directory. Spanish in "es" directory. My script will determine which
> templates to access depending on the visitor's language preference.
>
> Now, in a template I might have an option box for "male or female". In
> Spanish, "hombre or mujer." This language difference is kept in the
> template, and an ordinal is used to communicate to the scripts what the
> choice was. Regardless of language, "1" is a male, and "2" is a female. So,
> in this case, it would defeat the strength of templates to call some other
> device to emit the option box. I'd have to store the language text in a
> MySQL table and pass it to the device that will create the option box. I'd
> rather not do that since the text logically belongs in the template instance
> for that language.
>
> So, yes, I could set a param name for "one" and "two" and "three". Which
> ever is set to boolean true, that would be the option line to get the
> "selected" attribute. But, that seems like a difficult way to do it. The
> conditional test for string value (in template::expression) would be easier.
> I could set a single param to "two" and in the template test for "one" or
> "two" or "three". One param name with different values. It just seemed like
> template::expression gave me *a lot* more things which, at this point, I
> agree are undesireable.
>
> Now that I think about it, I believe I could set a param name for "one" and
> "two" and "three" but instead of making them true and false (and using an if
> statement) I could set the correct one to "selected" and just let each
> variable be replaced by its value. Only one would have "selected" and it
> would be emitted at the correct option line.
>
> Do you know if it would be more efficient to set one var and use a
> conditional to determine which option select line to treat differently. Or,
> set many vars and let them all be replaced (to null except one).
>
> Thanks,
> Mark
>
>
>
> -------------------------------------------------------
> This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
> The Event For Linux Datacenter Solutions & Strategies in The Enterprise
> Linux in the Boardroom; in the Front Office; & in the Server Room
> http://www.enterpriselinuxforum.com
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>
|
|
From: Roger B. W. <ro...@fi...> - 2003-10-19 22:43:00
|
On Sun, Oct 19, 2003 at 12:53:24PM -0700, Mark Fuller wrote:
>I just found html::template and it's exactly what I was looking for. The
>only thing that is a minor shortcoming for me is the inability to do option
>select lists. I understand the emphasis on keeping a template a template
>(and languages separate). But, here's an example of why I believe it is
>justifiable to provide for an "if" inside the variable loop that would emit
>an option list.
You know, you can do it quite easily without extending HTML::Template.
Here's how I do it. Say I have modes "a", "b" and "c", each of which
will produce different text. (Never mind different languages - I use
this trick for whole different pages in a multiscreen application.) Then
I just turn off die_on_bad_params, and set:
$tmpl->param(mode => $mode,
"mode.$mode" => 1);
Then the template has:
<tmpl_if name=mode.a>
text for mode A
</tmpl_if>
<tmpl_if name=mode.b>
text for mode B
</tmpl_if>
...and so on. You get the idea...
Roger
|
|
From: Mark F. <mar...@ea...> - 2004-05-03 20:57:23
|
I am creating a select list where all the "option" content comes from a mySQL table. The following works fine: ==================== Occupation: <select name="occupation"> <TMPL_LOOP NAME=OCCUPATION_LOOP> <option value="<TMPL_VAR NAME=VAL>"><TMPL_VAR NAME=TEXT></option> </TMPL_LOOP> ==================== How can I specify a row should be "selected"? The TMPL_VAR named "VAL" is a numeric index. If I could use TMPL_IF and concatenate the value of "VAL", I think it would work. <TMPL_IF NAME="SEL"<TMPL_VAR NAME="VAL">> selected </TMPL_IF> In my program I could set "$sel5 = 1". Is there any way to do this? Thanks, Mark |
|
From: Puneet K. <pk...@ei...> - 2004-05-03 21:13:47
|
Mark Fuller wrote:
> I am creating a select list where all the "option" content comes from a
> mySQL table. The following works fine:
>
> ====================
> Occupation: <select name="occupation">
> <TMPL_LOOP NAME=OCCUPATION_LOOP>
> <option value="<TMPL_VAR NAME=VAL>"><TMPL_VAR NAME=TEXT></option>
> </TMPL_LOOP>
> ====================
>
> How can I specify a row should be "selected"? The TMPL_VAR named "VAL" is a
> numeric index. If I could use TMPL_IF and concatenate the value of "VAL", I
> think it would work.
>
> <TMPL_IF NAME="SEL"<TMPL_VAR NAME="VAL">>
> selected
> </TMPL_IF>
>
> In my program I could set "$sel5 = 1".
>
> Is there any way to do this?
>
there are several ways to do this. I prefer simply constructing my sql
in such a way that the selected value is identified
SELECT val,
text,
(if then else to return 'selected' or '') AS selected
FROM table
WHERE whatever...
then in my template...
<tmpl_loop occupations>
<option value="<tmpl_var val>" <tmpl_var selected>>
<tmpl_var text>
</option>
</tmpl_loop>
|
|
From: Mark F. <mar...@ea...> - 2004-05-03 21:16:25
|
Thanks. That will work perfectly. Mark ----- Original Message ----- From: "Puneet Kishor" <pk...@ei...> To: "Mark Fuller" <mar...@ea...> Cc: <htm...@li...> Sent: Monday, May 03, 2004 2:13 PM Subject: Re: [htmltmpl] Select/option How to set "selected"? > Mark Fuller wrote: > > I am creating a select list where all the "option" content comes from a > > mySQL table. The following works fine: > > > > ==================== > > Occupation: <select name="occupation"> > > <TMPL_LOOP NAME=OCCUPATION_LOOP> > > <option value="<TMPL_VAR NAME=VAL>"><TMPL_VAR NAME=TEXT></option> > > </TMPL_LOOP> > > ==================== > > > > How can I specify a row should be "selected"? The TMPL_VAR named "VAL" is a > > numeric index. If I could use TMPL_IF and concatenate the value of "VAL", I > > think it would work. > > > > <TMPL_IF NAME="SEL"<TMPL_VAR NAME="VAL">> > > selected > > </TMPL_IF> > > > > In my program I could set "$sel5 = 1". > > > > Is there any way to do this? > > > > > there are several ways to do this. I prefer simply constructing my sql > in such a way that the selected value is identified > > SELECT val, > text, > (if then else to return 'selected' or '') AS selected > FROM table > WHERE whatever... > > then in my template... > > <tmpl_loop occupations> > <option value="<tmpl_var val>" <tmpl_var selected>> > <tmpl_var text> > </option> > </tmpl_loop> |
|
From: Jason P. <ja...@jo...> - 2004-05-03 21:37:01
|
Hi Mark,
How are you determining which option to pre-select? It might be better
to use HTML::FillInForm.
Other than that, here's what you would do if you want to re-invent the
wheel:
### In your programming code ###
my $template = HTML::Template->new( 'filename' => 'file.TMPL' );
my $occloop_ar = []; # occupation loop array ref.
while ( my ( $option, $value ) = $sth->fetchrow_array ) {
my $selected = 0;
$selected = 1 if i_want_this_option_selected( $option );
push @$array_ref, {
'VAL' => $option,
'TEXT' => $value,
'SELECTED' => $selected,
};
}
$template->param( 'OCCUPATION_LOOP' => $occloop_ar );
### Then in your template code ###
Occupation: <select name="occupation">
<TMPL_LOOP NAME=OCCUPATION_LOOP>
<option value="<TMPL_VAR NAME=VAL>" <TMPL_IF
NAME="SELECTED">SELECTED</TMPL_IF>><TMPL_VAR NAME=TEXT></option>
</TMPL_LOOP>
Cheers,
Jason
|
|
From: Mark F. <mar...@ea...> - 2004-05-03 22:44:28
|
Jason, thanks. The way you do the push helped me. I was putting the values
into a temporary hash and then assigning the hash as a reference. I wanted
to do it more directly like you did, but didn't know the semantics.
Regarding this:
> $selected = 1 if i_want_this_option_selected( $option );
and
> <TMPL_LOOP NAME=OCCUPATION_LOOP>
> <option value="<TMPL_VAR NAME=VAL>" <TMPL_IF
> NAME="SELECTED">SELECTED</TMPL_IF>><TMPL_VAR NAME=TEXT></option>
> </TMPL_LOOP>
Do you think this is more efficient, or is it more efficient to do as Puneet
suggested:
> $selected = ' selected' if i_want_this_option_selected( $option );
and
> <TMPL_LOOP NAME=OCCUPATION_LOOP>
> <option value="<TMPL_VAR NAME=VAL>"<TMPL_VAR NAME=SELECTED>><TMPL_VAR
NAME=TEXT></option>
> </TMPL_LOOP>
It seems to me the latter would be more efficient? If I am already testing
my criteria for selected, then I don't have to do an "if" again in the HTML.
In other words, is it more efficient to resolve the variable contents, or to
test variable?
Mark
----- Original Message -----
From: "Jason Purdy" <ja...@jo...>
To: "Mark Fuller" <mar...@ea...>
Cc: <htm...@li...>
Sent: Monday, May 03, 2004 2:36 PM
Subject: Re: [htmltmpl] Select/option How to set "selected"?
> Hi Mark,
>
> How are you determining which option to pre-select? It might be better
> to use HTML::FillInForm.
>
> Other than that, here's what you would do if you want to re-invent the
> wheel:
>
> ### In your programming code ###
> my $template = HTML::Template->new( 'filename' => 'file.TMPL' );
> my $occloop_ar = []; # occupation loop array ref.
> while ( my ( $option, $value ) = $sth->fetchrow_array ) {
> my $selected = 0;
> $selected = 1 if i_want_this_option_selected( $option );
> push @$array_ref, {
> 'VAL' => $option,
> 'TEXT' => $value,
> 'SELECTED' => $selected,
> };
> }
> $template->param( 'OCCUPATION_LOOP' => $occloop_ar );
>
> ### Then in your template code ###
> Occupation: <select name="occupation">
> <TMPL_LOOP NAME=OCCUPATION_LOOP>
> <option value="<TMPL_VAR NAME=VAL>" <TMPL_IF
> NAME="SELECTED">SELECTED</TMPL_IF>><TMPL_VAR NAME=TEXT></option>
> </TMPL_LOOP>
>
> Cheers,
>
> Jason
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
|
|
From: Puneet K. <pk...@ei...> - 2004-05-03 22:54:14
|
Mark Fuller wrote:
> Jason, thanks. The way you do the push helped me. I was putting the values
> into a temporary hash and then assigning the hash as a reference. I wanted
> to do it more directly like you did, but didn't know the semantics.
>
> Regarding this:
>
>
>> $selected = 1 if i_want_this_option_selected( $option );
>
> and
>
>><TMPL_LOOP NAME=OCCUPATION_LOOP>
>><option value="<TMPL_VAR NAME=VAL>" <TMPL_IF
>>NAME="SELECTED">SELECTED</TMPL_IF>><TMPL_VAR NAME=TEXT></option>
>></TMPL_LOOP>
>
>
> Do you think this is more efficient, or is it more efficient to do as Puneet
> suggested:
definitely as Puneet suggested ;-).
Seriously, unless you are dealing with gazillions of moolabytes of data
being hit every second by the entire population of Wyoming, don't sweat.
That said, my philosophy is to dump as much work on the database as
possible. Why? -- because db programs have been developed over years and
years (not that Perl has not been, but your or my code may not have the
same advantage), db servers are typically fast machines, db software
have been honed to do set processing, evaluations, calculations, etc.
There is a lot of science behind db theory. Definitely use it to your
advantage.
Of course, not everything is amenable to a SQL statement. That is where
Perl can shine.
>
>
>> $selected = ' selected' if i_want_this_option_selected( $option );
>
> and
>
>><TMPL_LOOP NAME=OCCUPATION_LOOP>
>><option value="<TMPL_VAR NAME=VAL>"<TMPL_VAR NAME=SELECTED>><TMPL_VAR
>
> NAME=TEXT></option>
>
>></TMPL_LOOP>
>
>
> It seems to me the latter would be more efficient? If I am already testing
> my criteria for selected, then I don't have to do an "if" again in the HTML.
> In other words, is it more efficient to resolve the variable contents, or to
> test variable?
>
> Mark
>
> ----- Original Message -----
> From: "Jason Purdy" <ja...@jo...>
> To: "Mark Fuller" <mar...@ea...>
> Cc: <htm...@li...>
> Sent: Monday, May 03, 2004 2:36 PM
> Subject: Re: [htmltmpl] Select/option How to set "selected"?
>
>
>
>>Hi Mark,
>>
>>How are you determining which option to pre-select? It might be better
>>to use HTML::FillInForm.
>>
>>Other than that, here's what you would do if you want to re-invent the
>>wheel:
>>
>>### In your programming code ###
>>my $template = HTML::Template->new( 'filename' => 'file.TMPL' );
>>my $occloop_ar = []; # occupation loop array ref.
>>while ( my ( $option, $value ) = $sth->fetchrow_array ) {
>> my $selected = 0;
>> $selected = 1 if i_want_this_option_selected( $option );
>> push @$array_ref, {
>> 'VAL' => $option,
>> 'TEXT' => $value,
>> 'SELECTED' => $selected,
>> };
>>}
>>$template->param( 'OCCUPATION_LOOP' => $occloop_ar );
>>
>>### Then in your template code ###
>>Occupation: <select name="occupation">
>><TMPL_LOOP NAME=OCCUPATION_LOOP>
>><option value="<TMPL_VAR NAME=VAL>" <TMPL_IF
>>NAME="SELECTED">SELECTED</TMPL_IF>><TMPL_VAR NAME=TEXT></option>
>></TMPL_LOOP>
>>
>>Cheers,
>>
>>Jason
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: Oracle 10g
>>Get certified on the hottest thing ever to hit the market... Oracle 10g.
>>Take an Oracle 10g class now, and we'll give you the exam FREE.
>>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>>_______________________________________________
>>Html-template-users mailing list
>>Htm...@li...
>>https://lists.sourceforge.net/lists/listinfo/html-template-users
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
|
|
From: Jason P. <ja...@jo...> - 2004-05-04 02:38:00
|
> That said, my philosophy is to dump as much work on the database as
> possible. Why? -- because db programs have been developed over years and
> years (not that Perl has not been, but your or my code may not have the
> same advantage), db servers are typically fast machines, db software
> have been honed to do set processing, evaluations, calculations, etc.
> There is a lot of science behind db theory. Definitely use it to your
> advantage.
I definitely agree here -- I didn't think about using SQL to do the
selected part ... kinda neat. :)
What's really neat if you do it like that is you can use DBI's
fetchall_arrayref method and be really snazzy:
my $template = HTML::Template->new( 'filename' => 'file.TMPL' );
my $sth = $dbh->prepare( <<_SQL_ );
SELECT val,
text,
(if then else to return 'selected' or '') AS selected
FROM table
WHERE whatever...
_SQL_
$sth->execute();
$template->param( 'OCCUPATION_LOOP' => $sth->fetchall_arrayref( {} ) );
## Note that the fetchall_arrayref doesn't save you computing time --
## it's only a shortcut and does the same thing as your loop to go
## through the results
---
What's neat about this, too is that it simplifies the template code, as
Puneet laid out.
Cheers,
Jason
|
|
From: Mathew R. <mat...@re...> - 2004-05-04 03:26:54
|
> What's really neat if you do it like that is you can use DBI's=20
> fetchall_arrayref method and be really snazzy:
>=20
> my $template =3D HTML::Template->new( 'filename' =3D> 'file.TMPL' );
> my $sth =3D $dbh->prepare( <<_SQL_ );
> SELECT val,
> text,
> (if then else to return 'selected' or '') AS selected
> FROM table
> WHERE whatever...
> _SQL_
> $sth->execute();
> $template->param( 'OCCUPATION_LOOP' =3D> $sth->fetchall_arrayref( {} ) =
);
> ## Note that the fetchall_arrayref doesn't save you computing time --
> ## it's only a shortcut and does the same thing as your loop to go
> ## through the results
> ---
>=20
> What's neat about this, too is that it simplifies the template code, =
as=20
> Puneet laid out.
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.
Mathew
|
|
From: Mark F. <mar...@ea...> - 2004-05-04 04:54:51
|
Matthew, I don't understand what's wrong with Jason's example. If DBI yields
a result in the format HTML::Template understands, what's wrong with taking
advantage of that? How would you change his example to make it more indirect
and abstract?
I love HTML::Template. Especially in combination with CGI::Application. But,
sometimes a database structure naturally lends itself to a form structure.
Doesn't it? Why is it wrong to pump the SQL output directly to
HTML::Template?
Mark
----- Original Message -----
From: "Mathew Robertson" <mat...@re...>
To: <htm...@li...>
Sent: Monday, May 03, 2004 8:26 PM
Subject: Re: [htmltmpl] Select/option How to set "selected"?
> What's really neat if you do it like that is you can use DBI's
> fetchall_arrayref method and be really snazzy:
>
> my $template = HTML::Template->new( 'filename' => 'file.TMPL' );
> my $sth = $dbh->prepare( <<_SQL_ );
> SELECT val,
> text,
> (if then else to return 'selected' or '') AS selected
> FROM table
> WHERE whatever...
> _SQL_
> $sth->execute();
> $template->param( 'OCCUPATION_LOOP' => $sth->fetchall_arrayref( {} ) );
> ## Note that the fetchall_arrayref doesn't save you computing time --
> ## it's only a shortcut and does the same thing as your loop to go
> ## through the results
> ---
>
> What's neat about this, too is that it simplifies the template code, as
> Puneet laid out.
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.
Mathew
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id149&alloc_id66&op=ick
_______________________________________________
Html-template-users mailing list
Htm...@li...
https://lists.sourceforge.net/lists/listinfo/html-template-users
|
|
From: Mathew R. <mat...@re...> - 2004-05-06 06:25:20
|
> Matthew, I don't understand what's wrong with Jason's example. If DBI =
yields
> a result in the format HTML::Template understands, what's wrong with =
taking
> advantage of that? How would you change his example to make it more =
indirect
> and abstract?
I would do something like:
{
my $sql_result =3D $db->fetch...
my @output;
foreach (@{$sql_result}) {
my $tmp;
$tmp->{name} =3D $_->[0];
if ($_->[0] =3D=3D 'fred') { $tmp->{selected} =3D 1; }
push @output, $tmp;
}
template->param( 'some_loop' =3D> \@output);
}
this makes the 'some_loop' TMPL_LOOP become reasonably abstract, as used =
below...
> I love HTML::Template. Especially in combination with =
CGI::Application. But,
> sometimes a database structure naturally lends itself to a form =
structure.
> Doesn't it? Why is it wrong to pump the SQL output directly to
> HTML::Template?
nothing is wrong with it per se... its all a matter of opinion...
I personally like the fact that I can do something like list with the =
TMPL_LOOP:
<TMPL_LOOP some_loop>
<TMPL_IF EXPR=3D"(__counter__ % 3) =3D=3D 1">
<tr valign=3Dtop>
</TMPL_IF>
<td width=3D33% align=3Dcenter valign=3Dtop class=3Dtext>
... some info...
<TMPL_IF selected>
.... entry selected
</TMPL_IF>
</td>
<TMPL_IF EXPR=3D"(__counter__ % 3) =3D=3D 0">
</tr>
<tr>
<td colspan=3D3>
<spacer>
</td>
</tr>
</TMPL_IF>
</TMPL_LOOP>
Basically this stuff takes the loop, then formats the output into three =
columns and multiple rows.
You can see here that the loop is no longer a combobox, but anthing that =
can be drawn using a table.
Thus, not tie'ing the output of the SQL to a specific format, allows me =
to use the same loop definition within:
1) as above
2) combobox
3) list of checkboxes / radiobuttons
4) arbitrary <UL> styled list where I color the selected item
Note, I also use a variation of the above code to display a picture =
gallery -> the Perl code doesn't need to care how I format the output =
(which would normally be done with nested TMPL_LOOP's).
This explain?
Mathew
>=20
> Mark
>=20
> ----- Original Message -----=20
> From: "Mathew Robertson" <mat...@re...>
> To: <htm...@li...>
> Sent: Monday, May 03, 2004 8:26 PM
> Subject: Re: [htmltmpl] Select/option How to set "selected"?
>=20
>=20
> > What's really neat if you do it like that is you can use DBI's
> > fetchall_arrayref method and be really snazzy:
> >
> > my $template =3D HTML::Template->new( 'filename' =3D> 'file.TMPL' );
> > my $sth =3D $dbh->prepare( <<_SQL_ );
> > SELECT val,
> > text,
> > (if then else to return 'selected' or '') AS selected
> > FROM table
> > WHERE whatever...
> > _SQL_
> > $sth->execute();
> > $template->param( 'OCCUPATION_LOOP' =3D> $sth->fetchall_arrayref( {} =
) );
> > ## Note that the fetchall_arrayref doesn't save you computing time =
--
> > ## it's only a shortcut and does the same thing as your loop to go
> > ## through the results
> > ---
> >
> > What's neat about this, too is that it simplifies the template code, =
as
> > Puneet laid out.
>=20
> 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.
>=20
> The purpose of H::T is to decopule the data from the presentation.
> Mathew
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id=8166&op=3Dick
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>=20
>
|
|
From: Cees H. <ce...@si...> - 2004-05-06 12:17:57
|
Mathew Robertson wrote:
>>Matthew, I don't understand what's wrong with Jason's example. If DBI yields
>>a result in the format HTML::Template understands, what's wrong with taking
>>advantage of that? How would you change his example to make it more indirect
>>and abstract?
>
>
> I would do something like:
>
> {
> my $sql_result = $db->fetch...
> my @output;
> foreach (@{$sql_result}) {
> my $tmp;
> $tmp->{name} = $_->[0];
> if ($_->[0] == 'fred') { $tmp->{selected} = 1; }
> push @output, $tmp;
> }
> template->param( 'some_loop' => \@output);
> }
>
> this makes the 'some_loop' TMPL_LOOP become reasonably abstract, as used below...
The point was to move that conditional into the database query instead
of doing it in perl. Your results would have been identical, except
that you set 'selected' => 1 and in the example given the user set
'selected' => 'SELECTED'. But both values are true, hence you could use
the example given and still have the flexibility that you require in the
template.
In Postgres you could do something like this to achieve the same result:
SELECT val, text, CASE WHEN val='fred' THEN 1 ELSE 0 END as selected
FROM table
WHERE whatever...
Then you can still use the $sth->fetchall_arrayref( {} ) method to pull
an array of hashes out of the database and pass it straight to your
template, thus removing the need for the loop and the conditionals in
your perl code.
Cheers,
Cees
|
|
From: Mark F. <mar...@ea...> - 2004-05-11 19:47:37
|
If I have something like this for readability in the template:
==============================
<TMPL_IF NAME="ERRMSG">
<p>Error: <TMPL_VAR NAME=ERRMSG>
<TMPL_IF NAME="EMAIL_AVAILABLE">
(Forgot your password? <a href="">Reset and email it to yourself</a>.)
</TMPL_IF>
</p>
</TMPL_IF>
================================
The resulting HTML has a lot of newlines.
I'd like to ask if there should'nt be a feature in H::T that would let the
template author selectively disable "rendering" linefeeds as meaningful
(intended) whitespace? What I am suggesting is an attribute for TMPL_IF (and
other operations?) named "NOLF" that would cause H::T to discard linefeeds?
My reasoning is: in HTML authoring there are ways to increase legibility of
the HTML without affecting the output of a parser. Or, more often, there are
ways to instruct the parser to treat what would otherwise be considered
whitespace for legibility of the HTML as whitespace intended for output by
the parser. H::T is just another layer from authoring to rendering.
Shouldn't it carry the same capability to provide for legibility without
affecting output?
It seems like there should be a way to express "TMPL_COMMENT" and
"TMPL_PRE". Or, if explicitly marking up whitespace that should be passed to
output is a bad idea, why not an attribute on some TMPL structures to
indicate they should *not* be treated as preformated text?
Sam, I noticed (in the archive) this was discussed before. At that time, it
seemed like it was just a question of whether the unwanted whitespace added
too much to the data being transferred. I agree that it's only a few bytes.
For a long table inside a loop, with a lot of ifs, and a lot of columns, the
bytes add up. But, more importantly, it seems like something is missing in
H::T when I get something out of it vastly different than I expected and I
have *no* way to prevent it. I could collapse my H::T statements. But, the
resulting illegibility of the template would (in my mind) only further
demonstrate that something is missing.
Thanks!
Mark
|
|
From: David H. <da...@ho...> - 2004-05-11 20:13:04
|
On 11 May 2004, at 20:47, Mark Fuller wrote: > If I have something like this for readability in the template: > > ============================== > <TMPL_IF NAME="ERRMSG"> > > <p>Error: <TMPL_VAR NAME=ERRMSG> > > <TMPL_IF NAME="EMAIL_AVAILABLE"> > > (Forgot your password? <a href="">Reset and email it to > yourself</a>.) > > </TMPL_IF> > > </p> > > </TMPL_IF> > ================================ > > The resulting HTML has a lot of newlines. > There are mod_perl and apache filters for doing this. mod_gzip makes it particularly academic if you're prepared to trade a little CPU for a *lot* of bandwidth. Stuff in the right place. -- Dave Hodgkinson CTO, Rockit Factory Ltd. http://www.rockitfactory.com/ Web sites for rock bands |
|
From: Mark F. <mar...@ea...> - 2004-05-11 20:16:46
|
From: "David Hodgkinson" <da...@ho...> > There are mod_perl and apache filters for doing this. mod_gzip makes it > particularly > academic if you're prepared to trade a little CPU for a *lot* of > bandwidth. > > Stuff in the right place. I don't agree with the assertion that mod_perl is the right place. I.e., why don't we use mod_perl to control whitespace handling with HTML? The <pre> and <!-- comment> elements seem like they're in the right place. Why would H::T be different? Mark |
|
From: Keith J. <kja...@ey...> - 2004-05-11 20:19:09
|
During previous discussions on this the suggestion was used to use tidy in some way. Obviously in HTML the whitespace is fairly harmless, but for an email template or using H::T for something other then HTML the whitespace makes a big difference. So I throw my vote in for a flag to include or not include the LF with certain H::T tags. On Tue, 2004-05-11 at 15:47, Mark Fuller wrote: > If I have something like this for readability in the template: > > ============================== > <TMPL_IF NAME="ERRMSG"> > > <p>Error: <TMPL_VAR NAME=ERRMSG> > > <TMPL_IF NAME="EMAIL_AVAILABLE"> > > (Forgot your password? <a href="">Reset and email it to yourself</a>.) > > </TMPL_IF> > > </p> > > </TMPL_IF> > ================================ > > The resulting HTML has a lot of newlines. > > I'd like to ask if there should'nt be a feature in H::T that would let the > template author selectively disable "rendering" linefeeds as meaningful > (intended) whitespace? What I am suggesting is an attribute for TMPL_IF (and > other operations?) named "NOLF" that would cause H::T to discard linefeeds? > > My reasoning is: in HTML authoring there are ways to increase legibility of > the HTML without affecting the output of a parser. Or, more often, there are > ways to instruct the parser to treat what would otherwise be considered > whitespace for legibility of the HTML as whitespace intended for output by > the parser. H::T is just another layer from authoring to rendering. > Shouldn't it carry the same capability to provide for legibility without > affecting output? > > It seems like there should be a way to express "TMPL_COMMENT" and > "TMPL_PRE". Or, if explicitly marking up whitespace that should be passed to > output is a bad idea, why not an attribute on some TMPL structures to > indicate they should *not* be treated as preformated text? > > Sam, I noticed (in the archive) this was discussed before. At that time, it > seemed like it was just a question of whether the unwanted whitespace added > too much to the data being transferred. I agree that it's only a few bytes. > For a long table inside a loop, with a lot of ifs, and a lot of columns, the > bytes add up. But, more importantly, it seems like something is missing in > H::T when I get something out of it vastly different than I expected and I > have *no* way to prevent it. I could collapse my H::T statements. But, the > resulting illegibility of the template would (in my mind) only further > demonstrate that something is missing. > > Thanks! > Mark > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to > deliver higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 > _______________________________________________ > Html-template-users mailing list > Htm...@li... > https://lists.sourceforge.net/lists/listinfo/html-template-users -- Keith Jackson <kja...@ey...> |
Thanks for helping keep SourceForge clean.
X