html-template-users — Discussion of HTML::Template and related modules

Re: [htmltmpl] RFC: external caching

[Carl F. <ca...@fi...>]

> I think I'd write that:
> 
>   use Storable qw(freeze);
>   $cache = freeze($t);
> 
> HTML::Template works fine with Storable - that's how the file_cache
> and shared_cache work.
> 
> -sam
> 

That didn't even cross my mind! I think that's exactly what I'll do.

The code I had written used Storable to save the {param_map} and 
parse_stack} keys, but your suggestion is obviously more maintainable 
and works on existing installations, nice.

Carl

Re: [htmltmpl] RFC: external caching

[Sam T. <sa...@tr...>]

On Wed, 12 May 2004, Carl Franks wrote:

> You can obtain a template to be saved externally as such:
>
> $cache = $t->output( cache_ref => 1 );

I think I'd write that:

  use Storable qw(freeze);
  $cache = freeze($t);

HTML::Template works fine with Storable - that's how the file_cache
and shared_cache work.

-sam

Re: [htmltmpl] Whitespace (linefeed) suppression?

[Pete P. <pet...@cy...>]

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

Re: [htmltmpl] Coding up a three column table...

[Carl F. <ca...@fi...>]

One way to do it might be:

use strict;
use Data::Dumper;

my $cols = 3;

my @foo = ({one => 1, ein => 1},    {two => 2, zwei => 2}, 
           {three => 3, drei => 3}, {four => 4, vier => 4});
my @bar;

for (my $n=0; $n<=$#foo; $n+=$cols) {
  my @row;
  for (1..$cols) {
    push @row, $foo[$n+($_-1)] if $foo[$n+($_-1)];
  }
  push @bar, \@row;
}

$t->param (loop => \@bar);

While not very pretty, it does have a configurable number of columns.

Carl

> 
> I've got an image gallery that I want displayed as three columns.
> 
> Am I right in assuming that I need to code it up as an array of rows
> containing the array of the column cells?
> 
> Anyone got any nice idiomatic perl for transforming a simple array
> into one of these? ;-)
> 
> Ta,
> 
> Dave
> 
> 
> -------------------------------------------------------
> 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
> 
> 

Re: [htmltmpl] Coding up a three column table...

[Roger B. W. <ro...@fi...>]

On Wed, May 12, 2004 at 10:05:03AM +0100, Dave Hodgkinson wrote:
>I've got an image gallery that I want displayed as three columns.
>Am I right in assuming that I need to code it up as an array of rows
>containing the array of the column cells?

No, but that's one way to do it. Another, and what I'd do if I were
feeling lazy, would be to use a single level of loop with extensions,
something like:

<table>
<tmpl_loop name=stuff>
<tmpl_if name=colstart>
  <tr>
</tmpl_if>
<td>your_content_here</td>
<tmpl_if name=colend>
  </tr>
</tmpl_if>
</tmpl_loop>
</table>

and just poke colstart and colend in the right place.

>Anyone got any nice idiomatic perl for transforming a simple array
>into one of these? ;-)

# generate @content with the image names and so on
for (my $n=0;$n<=$#content;$n+=3) {
  $content[$n]{colstart}=1;
}
for (my $n=2;$n<=$#content;$n+=3) {
  $content[$n]{colend}=1;
}
$content[-1]{colend}=1;

(warning, totally untested, but it probably works)

Roger

[htmltmpl] Coding up a three column table...

[Dave H. <da...@ho...>]

I've got an image gallery that I want displayed as three columns.

Am I right in assuming that I need to code it up as an array of rows
containing the array of the column cells?

Anyone got any nice idiomatic perl for transforming a simple array
into one of these? ;-)

Ta,

Dave

[htmltmpl] RFC: external caching

[Carl F. <ca...@fi...>]

Hi all,

I've coded and tested a new feature for the 'new' and 'output' methods 
and would like people's feedback on whether it might be accepted.

This feature request allows a parsed template structure to be output 
as a scalar ref, which can be fed back to the new method again.
Effectively this allows external caching.

USAGE
-----
You can obtain a template to be saved externally as such:

$cache = $t->output( cache_ref => 1 );

The externally saved template can be loaded as such:

my $t = HTML::Template->new( cacheref => $cache );
or 
my $t = HTML::Template->new_cache_ref( $cache );
or 
my $t = HTML::Template->new( type => 'cacheref', source => $cache );

REASON
------
I'm writing a web-app in which all configuration and data is saved in 
a database (excluding db connection vars).
The application allows an admin to (online) edit existing templates 
and create new templates for new 'themes'.
I have no desire to introduce the typical security hole of 
requiring '777' permission directories, just for the sake of the 
templating. Though I would like the benefit of some caching.

I would be using the above to save the pre-parsed template in the 
database, which would be fed to all 'new' method calls.

Before I post code, would it be best to submit a diff against the 
latest cpan release or the latest sourceforge cvs release?

Cheers,
Carl

Re: [htmltmpl] Patch to fix global_vars and loop problem...

[simran <sim...@re...>]

very good points :-) 

How is the attached as a patch... 

simran.




On Wed, 2004-05-12 at 14:09, Sam Tregar wrote:
> On Wed, 12 May 2004, simran wrote:
> 
> > +        foreach my $row (@$value) {
> > +          foreach my $key (keys %$row) {
> > +            $row->{$key} ||= "";
> > +          }
> > +        }
> 
> Hmmmm.  What happens when $row->{$key} is "0"?  What happens when
> undef is set in a loop within a loop?
> 
> I think the real fix is to find a way to use exists() rather than
> defined() when looking for the variable setting.  That way it doesn't
> matter what the value of the var is, just whether it's set or not.
> Maybe you could give that a try?
> 
> Thanks,
> -sam
> 
> 
> -------------------------------------------------------
> 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

Re: [htmltmpl] warning_on_bad_params (fwd)

[Gabor S. <ga...@pe...>]

On Tue, 11 May 2004, Karen J. Cravens wrote:

> On Wed, 12 May 2004, Gabor Szabo wrote:
>
> GS>Normally I'd do that but in our current setup he does not have a
> GS>test server and I don't have the templates :( quite crazy.
> GS>In any case he might later update the templates on the live server and
> GS>I'd like to get informed about missed params.
>
> Buy the mod_perl book... it has a lovely section on setting up test
> *instances* of a live server, without having to have a separate box, or
> compile, or anything.

You mean I can do it with only http access to that server ?

As in our current situation this is the only type of access I have.

Even the other guy has only simple user ssh access and he cannot change
the configuration of the web server.

But one assumption was correct, it is indeed Apache.

:-)    or rather :-( in my case.

Gabor

Re: [htmltmpl] Patch to fix global_vars and loop problem...

[Sam T. <sa...@tr...>]

On Wed, 12 May 2004, simran wrote:

> +        foreach my $row (@$value) {
> +          foreach my $key (keys %$row) {
> +            $row->{$key} ||= "";
> +          }
> +        }

Hmmmm.  What happens when $row->{$key} is "0"?  What happens when
undef is set in a loop within a loop?

I think the real fix is to find a way to use exists() rather than
defined() when looking for the variable setting.  That way it doesn't
matter what the value of the var is, just whether it's set or not.
Maybe you could give that a try?

Thanks,
-sam

[htmltmpl] Patch to fix global_vars and loop problem...

[simran <sim...@re...>]

Hi Sam, et al, 

Here are the details of (what i consider to be a bug anyway) a bug in
HTML::Template - its been bought up before, and you have mentioned that
it does need fixing, but it annoyed me enough today to produce a patch
for it and submit the patch :-) 

Take the following example:
 
========================================================================
test.tmpl:
----------
Global Variable gvar is: <tmpl_var name=gvar>

Loop: <tmpl_loop name=testloop>
        loopvar: <tmpl_var name=loopvar>
        gvar   : <tmpl_var name=gvar>
      </tmpl_loop>
========================================================================
test.pl
-------

use strict;
use HTML::Template;

my $t = new HTML::Template(filename => "test.tmpl", global_vars => 1,)
|| die;

my $testloop = [
    { loopvar => "GVar should be set",         gvar => "Loop GVar 1" },
    { loopvar => "GVar should be blank",       gvar => ""            },
    { loopvar => "GVar should be blank again", gvar => undef         },
];

$t->param(gvar     => "global variable");
$t->param(testloop => $testloop);
print $t->output();
========================================================================

When you run test.pl.. you get the following output:
------------------------------------------------------------------------
Global Variable gvar is: global variable

Loop: 
        loopvar: GVar should be set 
        gvar   : Loop GVar 1
      
        loopvar: GVar should be blank
        gvar   : 
      
        loopvar: GVar should be blank again
        gvar   : global variable
------------------------------------------------------------------------

Now, the issue is that "gvar" in the third iteration of the loop,
"should have been blank"... i explicitely set it to "undef" in the
code.. however, since global_vars was on, it ignored my "undef". 

Here's a patch that fixed the problem (using HTML::Template Version 2.6)
(it might not be the most efficient.. i've only quickly written
something that seems to work... but of course, you might want to check
its efficiency etc...)

========================================================================
--- Template.pm.orig	2004-05-12 12:29:01.000000000 +1000
+++ Template.pm	2004-05-12 12:42:58.000000000 +1000
@@ -2464,6 +2464,11 @@
     if (defined($value_type) and length($value_type) and ($value_type eq 'ARRAY' or ((ref($value) !~ /^(CODE)|(HASH)|(SCALAR)$/) and $value->isa('ARRAY')))) {
       (ref($param_map->{$param}) eq 'HTML::Template::LOOP') or
         croak("HTML::Template::param() : attempt to set parameter '$param' with an array ref - parameter is not a TMPL_LOOP!");
+        foreach my $row (@$value) {
+          foreach my $key (keys %$row) {
+            $row->{$key} ||= "";
+          }
+        }
       $param_map->{$param}[HTML::Template::LOOP::PARAM_SET] = [@{$value}];
     } else {
       (ref($param_map->{$param}) eq 'HTML::Template::VAR') or
========================================================================

simran.

Re: [htmltmpl] Whitespace (linefeed) suppression?

[Karen J. C. <si...@ph...>]

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...

Re: [htmltmpl] warning_on_bad_params

[Karen J. C. <si...@ph...>]

On Wed, 12 May 2004, Gabor Szabo wrote:

GS>Normally I'd do that but in our current setup he does not have a
GS>test server and I don't have the templates :( quite crazy.
GS>In any case he might later update the templates on the live server and
GS>I'd like to get informed about missed params.

Buy the mod_perl book... it has a lovely section on setting up test
*instances* of a live server, without having to have a separate box, or
compile, or anything.

(I learned more about Apache from the mod_perl book than I did from the
Apache book.  Go figure.)

-- 
Karen J. Cravens  si...@ph...

Re: [htmltmpl] Whitespace (linefeed) suppression?

[Mathew R. <mat...@re...>]

> > 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.

Re: [htmltmpl] Whitespace (linefeed) suppression?

[Clifton R. <cli...@ti...>]

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

Re: [htmltmpl] warning_on_bad_params

[Gabor S. <ga...@pe...>]

On Tue, 11 May 2004, Sam Tregar wrote:

> Sorry about that.  I meant to reply but got distracted.
no problem,

> Run with die_on_bad_params on your test server and turn it off in
> production.

Normally I'd do that but in our current setup he does not have a
test server and I don't have the templates :( quite crazy.
In any case he might later update the templates on the live server and
I'd like to get informed about missed params.


>
> > If it cannot be done now, would it be usefull if I tried to send
> > a patch for a warn_on_bad_params option set to 0 by default ?
>
> Hmmmm, maybe.  I've been meaning to do some work on the overall state
> of error messages in HTML::Template, possibly offering optional
> Exception::Class support.  If I did that I think it would be easy to
> also offer the ability to turn non-critical errors into warnings.  But
> a smaller change addressing just this problem might not be too bad...
>

Then I'll try to prepare a patch for that.

  Gabor

Re: [htmltmpl] warning_on_bad_params

[petersm <pe...@ve...>]

Gabor Szabo 

> The issues is that I created a simple set of templates that
> is used by someone to design a page from it.
> Sometimes he is missing a few of the <TMPL_...> codes, especially
> the new once I add.
> 
> When we put the pages online I'd like to be sure they won't crash
> because of bad params but I'd like to get some notification about
> these bad params.
> 
> How can I do this ?
> 
> If it cannot be done now, would it be usefull if I tried to send
> a patch for a warn_on_bad_params option set to 0 by default ?

I'd second that patch if you get it written.

Michael Peters
Venzia

Re: [htmltmpl] warning_on_bad_params

[Sam T. <sa...@tr...>]

On Wed, 12 May 2004, Gabor Szabo wrote:

> I asked this a couple of days ago with no response.
>
> I'd really appreciate your feedback.

Sorry about that.  I meant to reply but got distracted.

> When we put the pages online I'd like to be sure they won't crash
> because of bad params but I'd like to get some notification about
> these bad params.
>
> How can I do this ?

Run with die_on_bad_params on your test server and turn it off in
production.

> If it cannot be done now, would it be usefull if I tried to send
> a patch for a warn_on_bad_params option set to 0 by default ?

Hmmmm, maybe.  I've been meaning to do some work on the overall state
of error messages in HTML::Template, possibly offering optional
Exception::Class support.  If I did that I think it would be easy to
also offer the ability to turn non-critical errors into warnings.  But
a smaller change addressing just this problem might not be too bad...

-sam

Re: [htmltmpl] Whitespace (linefeed) suppression?

[Mark F. <mar...@ea...>]

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

Re: [htmltmpl] Whitespace (linefeed) suppression?

[Mark F. <mar...@ea...>]

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

Re: [htmltmpl] Whitespace (linefeed) suppression?

[Sam T. <sa...@tr...>]

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

Re: [htmltmpl] warning_on_bad_params

[Gabor S. <ga...@pe...>]

I asked this a couple of days ago with no response.

I'd really appreciate your feedback.

The issues is that I created a simple set of templates that
is used by someone to design a page from it.
Sometimes he is missing a few of the <TMPL_...> codes, especially
the new once I add.

When we put the pages online I'd like to be sure they won't crash
because of bad params but I'd like to get some notification about
these bad params.

How can I do this ?


If it cannot be done now, would it be usefull if I tried to send
a patch for a warn_on_bad_params option set to 0 by default ?

Gabor

Re: [htmltmpl] Whitespace (linefeed) suppression?

[Mark F. <mar...@ea...>]

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

Re: [htmltmpl] Whitespace (linefeed) suppression?

[Karen J. C. <si...@ph...>]

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...

Re: [htmltmpl] Whitespace (linefeed) suppression?

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

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