Thread: Re: [htmltmpl] Whitespace (linefeed) suppression? (Page 2)
Brought to you by:
samtregar
Menu
▾
▴
html-template-users
|
From: Puneet K. <pk...@ei...> - 2004-05-11 20:35:11
|
Keith Jackson wrote: > 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> >>================================ >> since we are voting, I would say 'no'. IMO, logic should belong in the script, not in the H-T markup, else it will become like php or coldfusion. The control tags (tmpl_if, tmpl_unless, etc.) provide basic programmatic control in the markup, but enough is enough, in my view. More often than not it is quite easy to rejig the code logic so the output comes out just the way you want it without having to resort to complicated control tags. Besides, H-T is good as it does exactly what you are asking it to do... you are putting whitespace (for legibility) and then asking the program to strip it out (for bandwidth)... just run htmltidy or whatever approp. tool to strip the whitespace out before putting it up for serving. I actually find H-T output to be quite pretty and compact. ;-) |
|
From: Mark F. <mar...@ea...> - 2004-05-11 21:09:50
|
From: "Puneet Kishor" <pk...@ei...> > IMO, logic should belong in the > script, not in the H-T markup, else it will become like php or > coldfusion. The control tags (tmpl_if, tmpl_unless, etc.) provide basic > programmatic control in the markup, but enough is enough, in my view. It seems like the problem (not a problem, but shortcoming?) is that the use of H::T tags leave residue linefeeds. The tags are removed, but not the linefeeds which were used *only* to enhance the legibility of why the tags were used. I agree with you. I don't want to see more logic tags. But, I don't think this kind of attribute regarding the whitespace used with H::T tags is that kind of logic. It's just an attribute of the existing tags regarding the whitespace that does or doesn't belong to them. > Besides, H-T is good as it does exactly what you are asking it to do... > you are putting whitespace (for legibility) and then asking the program > to strip it out (for bandwidth)... I just don't see it quite that way. I'm authoring a template and artifacts of that authoring are treated as HTML rather than template information. What you (and others) have said is that, if I don't want it to do this, then don't put whitespace in the template. My argument is that the result is an illegible template. Something's missing. I don't think post-processing the output is really the answer when I could just say "NOLF" while authoring. Mark |
|
From: Puneet K. <pk...@ei...> - 2004-05-11 21:36:31
|
Mark Fuller wrote: > From: "Puneet Kishor" <pk...@ei...> > >> IMO, logic should belong in the >>script, not in the H-T markup, else it will become like php or >>coldfusion. The control tags (tmpl_if, tmpl_unless, etc.) provide basic >>programmatic control in the markup, but enough is enough, in my view. > > > It seems like the problem (not a problem, but shortcoming?) is that the use > of H::T tags leave residue linefeeds. The tags are removed, but not the > linefeeds which were used *only* to enhance the legibility of why the tags > were used. that's the beauty. H-T removes just what it is concerned with... it uses tags, so it removes tags. It doesn't use whitespace, so it leaves it alone. don't get me wrong -- I do see the point of a whitespace remover as it would make something (in this case, the html source) nicer to look at. I am not sure if H-T is the place to do it. Besides, only Sam will be able to tell how complicated it will be to program H-T to figure out which whitespace to keep and which to remove. This kind of complexity usually comes with a price. As I have said in the past, I usually can think of ways something can be improved... but H-T is just one of those darn programs that I find can't be improved. It is close to perfect. It has a handful of commands, and I know most of them... beautiful. So leave it be. The thing is... it is so easy to get around this problem... as David suggested... what is wrong with either html-tidy, or with s/\n\n/\n/g |
|
From: Mark F. <mar...@ea...> - 2004-05-11 22:01:51
|
From: "Puneet Kishor" <pk...@ei...> > The thing is... it is so easy to get around this problem... as David > suggested... what is wrong with either html-tidy, or with s/\n\n/\n/g Nothing wrong with them. I only suggested it belongs in H::T. If the argument is that H::T shouldn't suffer the performance penalty of recognizing whitespace associated with legible use of its tags, then why would I want an even greater performance hit processing the whole document a second time? Just because an attribute like "NOLF" would cause additional processing to omit the emission of linefeeds while it is in effect, that doesn't mean you have to use it. You make it sound like you're going to suffer a performance penalty by this feature being present. And then proceed to suggest I suffer an even greater one. :) Honestly I do agree with the zealous guarding against too many things getting into H::T that don't belong there. But, this issue of whitepsace associated with the legible use of H::T tags seems like a legitimate one. If it doesn't belong in H::T then I think it leads to the absurd conclusion that legibility is not within the scope of H::T. Also, the suggestion that legibility should be accomodated by post-processing diminishes (IMO) arguments about keeping H::T lean and mean. On the one hand, don't sacrifce a single cycle. On the other hand, parse the entire document a second time just to have legible templates (without the artifacts). That doesn't seem reasonable to me. If I'm in the minority, or it's not up for a vote, then ok. It's not a terribly important issue. But I still think something is missing. Mark |
|
From: Karen J. C. <si...@ph...> - 2004-05-11 21:40:48
|
On Tue, 11 May 2004, Mark Fuller wrote: MF>Something's missing. I don't think post-processing the output is really the MF>answer when I could just say "NOLF" while authoring. FWIW, using whitespace *inside* the TMPL_IF statements goes a long way toward breaking things up without introducing extra stuff into the final document. You end up with peculiarly-placed angle brackets, and </TMPL_IF> resists the intrusion a bit, but you end up with no whitespace from this: <TMPL_IF this >That< TMPL_ELSE >The other</TMPL_IF > Of course, then one has to be extra careful to get the angle bracket count right. -- Karen J. Cravens si...@ph... |
|
From: David H. <da...@ho...> - 2004-05-11 20:56:22
|
On 11 May 2004, at 21:19, Keith Jackson wrote: > During previous discussions on this the suggestion was used to use tidy > in some way. running the template output through HTML::Tidy in some way is a no-brainer... > 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. as is s/\n\n/\n/g ! > > So I throw my vote in for a flag to include or not include the LF with > certain H::T tags. Ok, I'll buy this. Template::Toolkit has a variety of options for including or not whitespace after tags, either in the configs, or at the tag level, closing with -%]. -- Dave Hodgkinson CTO, Rockit Factory Ltd. http://www.rockitfactory.com/ Web sites for rock bands |
|
From: petersm <pe...@ve...> - 2004-05-11 20:24:55
|
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? Why should this matter (besides the bandwidth issue)? HTML ignores whitespace and other than looking at the output of a template every now and then to make sure that it is what you want, why do you care what the output looks like? I like the fact that it does exactly what you tell it to do. If you have whitespace it puts it in your loop. If you don't have whitespace it won't. Fairly intuitive to me. Anyone? Michael Peters Venzia |
|
From: Mark F. <mar...@ea...> - 2004-05-11 20:55:38
|
From: "petersm" <pe...@ve...> > Why should this matter (besides the bandwidth issue)? HTML ignores whitespace > and other than looking at the output of a template every now and then to make > sure that it is what you want, why do you care what the output looks like? Why take bandwidth off the table? I gave an example (of a table) where the whitespace could be significant. And, as has been mentioned, there are occasions when the unintended whitespace *does* affect the final rendering. In one prior discussion someone gave an example of the <image> element. Keith just gave an example concerning email. (It may not have come out on the list by the time you replied to me). The question of why I would care what H::T output looks like is subjective. Someone could suggest that I put all the H::T elements on one line and ask "why do you care what the template looks like?" Authoring is subjective. I just don't think I should get something out of H::T that I didn't intend. I don't think the tags should influence the resulting whitespace. The tags are eliminated, but whitespace associated with them is not. Is that really a "problem?" To me, it's just a subjective issue that I'd like the resulting HTML be closer to how I would author it if I hadn't used H::T tags. I'm getting something in the output that I didn't specify. > I like the fact that it does exactly what you tell it to do. If you have > whitespace it puts it in your loop. If you don't have whitespace it won't. > Fairly intuitive to me. Anyone? My argument is that I *can't* tell it what to do. :) The only solution is to remove the whitespace which will result in a very illegible template. Which takes me back to my comparison to HTML authoring and how legibility (without affecting the parser results) is provided for. I guess my argument is that it's not *only* a matter of being intuitive when/where to use whitespace. There are two kinds of whitespace. Maybe the only questions are 1. Is it it is valid to consider there are two types of whitespace. 2. Should the use of H::T tags result in whitespace you wouldn't have if you didn't use them? Thanks! Mark |
|
From: Clifton R. <cli...@ti...> - 2004-05-11 22:49:43
|
On Tue, May 11, 2004 at 01:55:38PM -0700, Mark Fuller wrote:
> From: "petersm" <pe...@ve...>
> > Why should this matter (besides the bandwidth issue)? HTML ignores
> whitespace
> > and other than looking at the output of a template every now and then to
> make
> > sure that it is what you want, why do you care what the output looks like?
>
> Why take bandwidth off the table? I gave an example (of a table) where the
> whitespace could be significant. And, as has been mentioned, there are
> occasions when the unintended whitespace *does* affect the final rendering.
> In one prior discussion someone gave an example of the <image> element.
> Keith just gave an example concerning email. (It may not have come out on
> the list by the time you replied to me).
For those curious about one (fairly random) set of numbers, I found a
15-30% reduction in template size by running htmlclean (from
HTML::Clean) on my templates before installing them, with an average
somewhere around 25%. So, yeah, bandwidth is somewhat relevant. OTOH,
the way I got those numbers defines one solution to the bandwidth
issue.
> The question of why I would care what H::T output looks like is subjective.
> Someone could suggest that I put all the H::T elements on one line and ask
> "why do you care what the template looks like?" Authoring is subjective. I
> just don't think I should get something out of H::T that I didn't intend. I
> don't think the tags should influence the resulting whitespace.
...
Personally, I would like this feature, because we did briefly mess
around with trying to use HTML::Template for templating Ascii text
(email report generation) and found it overwhelmingly painful as it
stands. We simply deferred the text-only output feature and have had
no complaints asking for it so far.
However, I didn't complain to this list at that time, because I
figured that after all, the package is called *HTML* Template, and
whitespace is defined as irrelevant to HTML. I decided back then that
if it turned out we really needed a system that would work equally well
for text and HTML, I'd switch to Template Toolkit or something like
that.
(Though having seen Karen's formatting suggestion, I think I'd try
that first. Neatly done!)
-- Clifton
--
Clifton Royston -- cli...@ti...
Tiki Technologies Lead Programmer/Software Architect
Did you ever fly a kite in bed? Did you ever walk with ten cats on your head?
Did you ever milk this kind of cow? Well we can do it. We know how.
If you never did, you should. These things are fun, and fun is good.
-- Dr. Seuss
|
|
From: Pete P. <pet...@cy...> - 2004-05-12 13:44:57
|
petersm wrote: > 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? > > > Why should this matter (besides the bandwidth issue)? HTML ignores whitespace > and other than looking at the output of a template every now and then to make > sure that it is what you want, why do you care what the output looks like? > > I like the fact that it does exactly what you tell it to do. If you have > whitespace it puts it in your loop. If you don't have whitespace it won't. > Fairly intuitive to me. Anyone? Ah, this reminds me of when I had to use ColdFusion, and the code was producing *hundreds* and *hundreds* of lines of whitespace (I think this was a v4.5 issue that was later somewhat 'fixed') Anyway, bandwidth became a huge issue, as the pages were pretty hefty to begin with. It sounds like a feature that may be useful to some where every kbyte and second really matter. Pete |
|
From: Sam T. <sa...@tr...> - 2004-05-11 21:27:16
|
On Tue, 11 May 2004, Mark Fuller wrote: > It seems like there should be a way to express "TMPL_COMMENT" <tmpl_if comment>....</tmpl_if> Then don't define "comment". Compare to the POD "=begin comment" convention which is very similar. > 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. In my opinion, the problem is in your expectation. HTML::Template gives you back exactly what you put in the template, plus the variables and loops you defined in your Perl code. Nothing more, nothing less. If you want to clean or compress your HTML output you might be interested in HTML::Clean or one of the many Apache modules which address this problem. I consider this to be outside the scope of HTML::Template. -sam |
|
From: Mark F. <mar...@ea...> - 2004-05-11 21:45:01
|
From: "Sam Tregar" <sa...@tr...> > In my opinion, the problem is in your expectation. HTML::Template > gives you back exactly what you put in the template, ... > ... I consider this to be outside the scope of HTML::Template. I'm sorry. I was hoping you'd see the legitimacy of my suggestion. I don't think you're saying this, but doesn't your decision ultimately mean legibility of the template is outside the scope of H::T? On the one hand you're saying H::T does exactly what you tell it to do. On the other hand, if you write it legibly but don't like all the artifacts in your output, then don't write it legibly. Is that reasonable? Also, if the solution is to post-process the output to remove artifacts from authoring legible templates, wouldn't it be better to author my templates legibly with my own "NOLF" attribute and pre-process it to make it illegible (and remove my "NOLF" attribute) before publishing it to the server. Then the processing only occurs once instead of each time the page is served. That last point might sound absurd. But, I think both points are why I felt this was a legitimate suggestion. Ultimately, if you want to suppress whitespace you sacrifice legibility. If you want legibility, you either pre-process the template to remove the legibility, or post-process to remove the linefeeds associated with legibility. This doesn't sound reasonable to me. Mark |
|
From: Sam T. <sa...@tr...> - 2004-05-11 21:55:14
|
On Tue, 11 May 2004, Mark Fuller wrote: > I don't think you're saying this, but doesn't your decision ultimately mean > legibility of the template is outside the scope of H::T? On the one hand > you're saying H::T does exactly what you tell it to do. On the other hand, > if you write it legibly but don't like all the artifacts in your output, > then don't write it legibly. Is that reasonable? That sounds ok, but I would add that if you want to write your templates in one style and see output in another then you are perfectly free to do so. Just write some code that takes the HTML from output() and modifies it to your specifications. Or, alternately, write a filter which you can pass to HTML::Template->new() to fixup the template before it's seen by HTML::Template. > Also, if the solution is to post-process the output to remove artifacts from > authoring legible templates, wouldn't it be better to author my templates > legibly with my own "NOLF" attribute and pre-process it to make it illegible > (and remove my "NOLF" attribute) before publishing it to the server. Then > the processing only occurs once instead of each time the page is served. I wouldn't worry so much about the runtime performance of a couple regular expressions, if that's all it would be. The time you spend on them will likely be dwarfed by database and network bottlenecks. Of course the only way to tell for sure would be to benchmark. Also, if you code your solution as a filter and use HTML::Template's caching then the filter will only be run once and the result used on each subsequent call. -sam |
|
From: Mathew R. <mat...@re...> - 2004-05-11 23:34:44
|
> > I don't think you're saying this, but doesn't your decision = ultimately mean > > legibility of the template is outside the scope of H::T? On the one = hand > > you're saying H::T does exactly what you tell it to do. On the other = hand, > > if you write it legibly but don't like all the artifacts in your = output, > > then don't write it legibly. Is that reasonable? >=20 > That sounds ok, but I would add that if you want to write your > templates in one style and see output in another then you are > perfectly free to do so. Just write some code that takes the HTML > from output() and modifies it to your specifications. Or, > alternately, write a filter which you can pass to > HTML::Template->new() to fixup the template before it's seen by > HTML::Template. I'd second this design - it would be relatively easy to make a filter = which stripped out whitespace between TMPL tags and normal text, based = on some sort of rules. That way, your templates look good, and your = html output looks good. For what its worth: our company strips all irrelevant whitespace, as = well as html and javascript comments from our HTML based reports -> this = usually results in a 30% reduction in the resulting HTML; we then use = mod_gzip for a further bandwidth reduction. Mathew PS. if a filter is written to accomodate this requirement, please = forward it to me so that I can add it to the other filters in the = H::T:Filters package. |
|
From: Mathew R. <mat...@re...> - 2004-05-03 22:55:15
|
The difference would be not be measurable unless you did a 1,000,000 =
instantations, then timed the results, since both Perl and H::T are =
reasonably quick a text processing.
Mathew
----- Original Message -----=20
From: "Mark Fuller" <mar...@ea...>
To: <ja...@jo...>
Cc: <htm...@li...>
Sent: Tuesday, May 04, 2004 8:43 AM
Subject: Re: [htmltmpl] Select/option How to set "selected"?
> 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.
>=20
> Regarding this:
>=20
> > $selected =3D 1 if i_want_this_option_selected( $option );
> and
> > <TMPL_LOOP NAME=3DOCCUPATION_LOOP>
> > <option value=3D"<TMPL_VAR NAME=3DVAL>" <TMPL_IF
> > NAME=3D"SELECTED">SELECTED</TMPL_IF>><TMPL_VAR NAME=3DTEXT></option>
> > </TMPL_LOOP>
>=20
> Do you think this is more efficient, or is it more efficient to do as =
Puneet
> suggested:
>=20
> > $selected =3D ' selected' if i_want_this_option_selected( $option =
);
> and
> > <TMPL_LOOP NAME=3DOCCUPATION_LOOP>
> > <option value=3D"<TMPL_VAR NAME=3DVAL>"<TMPL_VAR =
NAME=3DSELECTED>><TMPL_VAR
> NAME=3DTEXT></option>
> > </TMPL_LOOP>
>=20
> 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?
>=20
> Mark
>=20
> ----- Original Message -----=20
> 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"?
>=20
>=20
> > 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 =3D HTML::Template->new( 'filename' =3D> 'file.TMPL' );
> > my $occloop_ar =3D []; # occupation loop array ref.
> > while ( my ( $option, $value ) =3D $sth->fetchrow_array ) {
> > my $selected =3D 0;
> > $selected =3D 1 if i_want_this_option_selected( $option );
> > push @$array_ref, {
> > 'VAL' =3D> $option,
> > 'TEXT' =3D> $value,
> > 'SELECTED' =3D> $selected,
> > };
> > }
> > $template->param( 'OCCUPATION_LOOP' =3D> $occloop_ar );
> >
> > ### Then in your template code ###
> > Occupation: <select name=3D"occupation">
> > <TMPL_LOOP NAME=3DOCCUPATION_LOOP>
> > <option value=3D"<TMPL_VAR NAME=3DVAL>" <TMPL_IF
> > NAME=3D"SELECTED">SELECTED</TMPL_IF>><TMPL_VAR NAME=3DTEXT></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=3D3149&alloc_id=3D8166&op=3Dclick
> > _______________________________________________
> > Html-template-users mailing list
> > Htm...@li...
> > https://lists.sourceforge.net/lists/listinfo/html-template-users
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle =
10g.=20
> Take an Oracle 10g class now, and we'll give you the exam FREE.=20
> http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>
|
|
From: Karen J. C. <si...@ph...> - 2004-05-03 23:00:21
|
On Mon, 3 May 2004, Mark Fuller wrote: MF>It seems to me the latter would be more efficient? If I am already testing MF>my criteria for selected, then I don't have to do an "if" again in the HTML. MF>In other words, is it more efficient to resolve the variable contents, or to MF>test variable? The main thing the TMPL_IF offers is the choice for the template writer to change the format. If you hardcode it to "SELECTED" you're requiring a selection box, vs. radio buttons (which use "CHECKED"). (Well, technically if you leave the non-selected ones blank you *could* still use it in a TMPL_IF, but that's a bit risky...) -- Karen J. Cravens si...@ph... |
|
From: Sam T. <sa...@tr...> - 2004-05-04 03:46:20
|
On Mon, 3 May 2004, Mark Fuller wrote: > 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. I just use CGI.pm's popup_menu(). I find that it's pretty rare for HTML designers to need to do something to the form tags themselves so I usually let CGI.pm to do the hard work for me. You certainly can accomplish this with HTML::Template, but I don't think you're going to like the look of what it takes! -sam |
|
From: Mark F. <mar...@ea...> - 2004-05-04 04:11:58
|
Thanks Sam. I try to stay away from CGI.pm. In my opinion, it should have been named HTML.pm. <smile> I just don't need all the HTML'ish routines. I use CGI:Simple. The suggestion from Puneet looks great. I don't have any problem with it. Yet.... :) By way of suggestion, the way HTML::Template has various "__first__, __last__, __counter__" helper fields, I wish there were a way to inform a loop of a special value used to indicate the row that should get the "selected" attribute. It seems like there's a lot of pragmatic helpers available, but nothing for what is a very basic HTML construct. Why not a reserved variable name like __selected__ and HTML::Template would fill it in automatically if a corresponding boolean is true for that row? Would this be any more efficient (or beautiful) than Puneet's suggestion? It just seems to me like "selected" and "checked" are fairly basic and there's no easy (more built-in) way to accomodate them. It seems like you recognize that they require a bit of ugliness. Why not provide for them somehow? It couldn't add more overhead than the loop variables mentioned above. (I support your quest to keep it clean and fast!). Mark ----- Original Message ----- From: "Sam Tregar" <sa...@tr...> To: "Mark Fuller" <mar...@ea...> Cc: <htm...@li...> Sent: Monday, May 03, 2004 8:42 PM Subject: Re: [htmltmpl] Select/option How to set "selected"? > On Mon, 3 May 2004, Mark Fuller wrote: > > > 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. > > I just use CGI.pm's popup_menu(). I find that it's pretty rare for > HTML designers to need to do something to the form tags themselves so > I usually let CGI.pm to do the hard work for me. You certainly can > accomplish this with HTML::Template, but I don't think you're going to > like the look of what it takes! > > -sam > > > > ------------------------------------------------------- > 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: Sam T. <sa...@tr...> - 2004-05-04 05:47:29
|
On Mon, 3 May 2004, Mark Fuller wrote:
> By way of suggestion, the way HTML::Template has various "__first__,
> __last__, __counter__" helper fields, I wish there were a way to inform a
> loop of a special value used to indicate the row that should get the
> "selected" attribute. It seems like there's a lot of pragmatic helpers
> available, but nothing for what is a very basic HTML construct. Why not a
> reserved variable name like __selected__ and HTML::Template would fill it in
> automatically if a corresponding boolean is true for that row? Would this be
> any more efficient (or beautiful) than Puneet's suggestion?
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?
> It just seems to me like "selected" and "checked" are fairly basic and
> there's no easy (more built-in) way to accomodate them. It seems like you
> recognize that they require a bit of ugliness. Why not provide for them
> somehow?
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.
-sam
|
|
From: Cees H. <ce...@si...> - 2004-05-04 18:44:19
|
Sam Tregar wrote: > On Mon, 3 May 2004, Mark Fuller wrote: >>It just seems to me like "selected" and "checked" are fairly basic and >>there's no easy (more built-in) way to accomodate them. It seems like you >>recognize that they require a bit of ugliness. Why not provide for them >>somehow? > > > 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. I have to agree with Sam on this one. I don't think there is a need to add features to handle select lists in HTML::Template. The issue of filling in HTML forms was solved ages ago, and doing it in HTML::Template is not (IMHO) the elegant way to do it. Use CGI.pm as Sam suggests, or use HTML::FillInForm (my preferred method). These days the only thing that needs to be customized in a form element that a designer may need access to is the class attribute. If you define a standard naming convention, then having the class attribute in your code is not a big deal (the code already defines the name of the form element as well...). If you need to change the style dynamically, then load a different stylesheet for the page. Don't change the name of the class attribute... The only thing that I can see where using CGI.pm to generate select boxes could hamper a designer is if they want to put a null option at the top of the list ( eg -- Choose a Year --). That would have to be encoded in the code which means the designer can't change it. That is one reason why I use HTML::FillInForm. I provide the template with a list of options (which the designer can put into a select box, or as a bunch of radio buttons formatted in a table, I don't care). Then HTML::FillInForm comes along afterwards and fills out the form regardless of how the designer decided to lay it out. Both methods simplify your templates a great deal, and make life much easier for the template designer. That having been said, nothing is stopping you from continuing on using HTML::Template to fill in forms. It is a valid method that works well for many people. Cheers, Cees |
|
From: Puneet K. <pk...@ei...> - 2004-05-04 13:20:56
|
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".
;-)
|
|
From: petersm <pe...@ve...> - 2004-05-04 14:31:33
|
Puneet Kishor wrote
>
> 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?).
There has been some recent discussion on the CGI::Application list of just
this issue. It seems that CGI::Session does a pretty strict test to make sure
that it has a CGI.pm object and not just a compatible object. I think some
work is underway to change this so that it does some tests for the param() and
cookie() methods. So, not right now, but maybe not too much later.
> > 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.
how about something like this that decouples the SQL from the HTML but is
still relatively simple (and uses XHTML instead of HTML )
in perl
.
.
my $sth = $dbi->prepare(qq(SELECT val, text, (val = "$selected") AS selected
FROM whatever WHERE whatever));
my $tmpl = HTML::Template->new();
$tmpl->param(occupations => $sth->fetchall_arrayref( {} );
in the tmpl (for a dropdown select box)
.
.
<select name='whatever'>
<TMPL_LOOP NAME=OCCUPATION_LOOP>
<option value="<TMPL_VAR NAME=VAL>" <TMPL_IF
NAME="SELECTED">selected='selected'</TMPL_IF>><TMPL_VAR NAME=TEXT></option>
</TMPL_LOOP>
</select>
or in the tmpl for a group of checkboxes, (or radio buttons)
.
.
<TMPL_LOOP NAME=OCCUPATION_LOOP>
<input type='checkbox' value="<TMPL_VAR NAME=VAL>" name='whatever' <TMPL_IF
NAME="SELECTED">checked='checked'</TMPL_IF> /><TMPL_VAR NAME=TEXT><br />
</TMPL_LOOP>
this way the same SQL creates a structure that is independent of the HTML but
still not so much so that it's hard to work with.
Michael Peters
Venzia
|
|
From: Sam T. <sa...@tr...> - 2004-05-04 17:21:19
|
On Tue, 4 May 2004, Puneet Kishor wrote: > 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. I've found that it's very unusual for designers to need to work on the form tags themselves. If they need to change anything it's usually just a matter of adding the appropriate CSS '-class' parameter. But I've only had to do that a few times. Much more common is the need to move form tags around, which is actually easier if the form tag is a simple '<tmpl_var foo_select>' and not a huge nest of if/else blocks. -sam |
|
From: Mark F. <mar...@ea...> - 2004-05-11 22:05:04
|
Thank you! That will work for me. I still think the unusual appearance of the solution points to something missing in H::T. But, I don't seem to be getting anywhere. :) Mark |
|
From: Karen J. C. <si...@ph...> - 2004-05-12 00:49:48
|
On Tue, 11 May 2004, Mark Fuller wrote: MF>Thank you! That will work for me. I still think the unusual appearance of MF>the solution points to something missing in H::T. But, I don't seem to be MF>getting anywhere. :) I dunno. Like I've said, I use H::T for building (non-HTML) email notifications and other text-only items, and while it'd be nice to somehow have H::T magically know about line breaks I want to keep vs. ones I don't, I haven't come up with a good way to delimit it. One thing I *do* do is edit templates using Arachnophilia. You can pop the "Beautify" icon, look over the deeply indented structure with vaahhhhst traaaahhhcts of whitespace, then hit "undo" so your final document doesn't look like that. (Usually. I suspect if you inspected the HTML on my whole server, you might see Arachnophiliated webpages here and there.) The only drawback *there* is that Arachnophilia is quite Windowscentric, and is thus anal about file extensions... so I have to rename my templates as .html during the course of the edit, instead of my usual .tmpl and .stmpl. They usually end up as filename.tmpl.html so as not to stomp on any filename.html versions that might occupy the same directory. No, make that two drawbacks: if you forget and save the file without undoing the Beautify-cation, you have to go and edit all the whitespace back out. -- Karen J. Cravens si...@ph... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X