html-template-users

RE: [htmltmpl] extra whitespace

[Paulsen, B. <BPa...@le...>]

I think a filter function would do this for you easily.

Something like this:

my $filter =3D sub {
     my $text_ref =3D shift;
     $$text_ref =3D~ s/(<TMPL_[~>]>)[\r\n]+/$1/g;
   };=20

-----Original Message-----
=46rom: htm...@li...
[mailto:htm...@li...] On Behalf Of
htm...@pa...
Sent: Wednesday, February 08, 2006 1:19 PM
To: htm...@li...
Subject: Re: [htmltmpl] extra whitespace

Rumour has it Alex Kapranoff, on or about 08.Feb.2006 12:57, whispered:
> * Alex Teslik <al...@ac...> [February 08 2006, 20:43]:
>>    Is there a switch (feature request=3F) that will tell HTMLTMPL to=20
>> replace a TMPL followed by [\n\r]+ with nothing - even better replace

>> the whole line if

<snip>

>> tag creates hard to read template files. In particular, this would be

>> useful for the TMPL_LOOP and TMPL_IF/UNLESS constructs.
>=20
> That would be very useful option indeed if done well and fast.
> I'd use it everywhere.
>=20

Oh yes indeedy.  Me too.

--
Chris Beck  -  http://pacanukeha.blogspot.com He needs a lang shanket
spoon that sups kail wi' the de'il


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
=66iles for problems=3F  Stop!  Download the new AJAX search engine that
makes searching your log files as easy as surfing the  web.  DOWNLOAD
SPLUNK!
http://sel.as-us.falkag.net/sel=3Fcmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
_______________________________________________
Html-template-users mailing list
Htm...@li...
https://lists.sourceforge.net/lists/listinfo/html-template-users




---------------------------------------------------------------------------=
---
This message is intended only for the personal and confidential use of the =
designated recipient(s) named above.  If you are not the intended recipient=
 =
of this message you are hereby notified that any review, dissemination, =
distribution or copying of this message is strictly prohibited.  This =
communication is for information purposes only and should not be regarded a=
s=
 an offer to sell or as a solicitation of an offer to buy any financial =
product, an official confirmation of any transaction, or as an official =
statement of Lehman Brothers.  Email transmission cannot be guaranteed to b=
e=
 secure or error-free.  Therefore, we do not represent that this informatio=
n=
 is complete or accurate and it should not be relied upon as such.  All =
information is subject to change without notice.
--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within =
this communication (including any attachments) is not intended or written t=
o=
 be used and cannot be used for the purpose of (i) avoiding U.S. tax relate=
d=
 penalties or (ii) promoting, marketing or recommending to another party an=
y=
 transaction or matter addressed herein.

Re: [htmltmpl] extra whitespace

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

From: Alex Teslik <al...@ac...>
>Is there a switch (feature request?) that will tell HTMLTMPL to replace a
>TMPL followed by [\n\r]+ with nothing - even better replace the whole line=
 if
>the only thing on the line is a TMPL tag?=20

I raised this issue a year or two ago and it wasn't well-received. It seems=
 like it's common for newcomers (as I was) to spot this and believe it's a =
shortcoming in H::T. Among experienced users, they believe it's easier and =
faster to use the "filter" option to strip *all* linefeeds if wasted bandwi=
dth is your motivation to remove some. If the performance overhead of using=
 the "filter" option is a concern, then preprocess your templates to load, =
filter and output them to another file which will be your template to be us=
ed at run-time.=20

I do this for other reasons, like if there is common processing to be appli=
ed to parts of the page once. For example: international language substitut=
ion of headings, labels, etc. I use tags prefixed as "PREPROC-" in my *mast=
er* template to differentiate things that need to be preprocessed versus th=
e tags that are dynamically set at run time. I use a batch script to load t=
he template and "filter" the TMPL- tags to "HOLD-" tags, change the "PREPRO=
C-" tags to "TMPL-" tags. I don't strip the linefeeds in this filter. I do =
my preprocessing to set TMPL-VARS and LOOPS as necessary for one-time initi=
alization of the page (for example, language substitution). I output the H:=
:T object to a variable and perform a regex on the variable to change all t=
he "HOLD-" tags to "TMPL-" tags. This is where I strip the linefeeds. Then =
print this variable to a file which will be the template used at runtime. S=
o, I have a master template (with includes, etc.) and a run-time template t=
hat needs no run-time processing except the actual variables that can chang=
e at run time (messages, dynamically generated lists, etc.).

That's probably a much more complicated example than what you need just to =
strip linefeeds. The filter option will work for you. I just wanted to demo=
nstrate that there's a lot of ways to solve a problem with H::T if you real=
ize you're not stuck with just one preconceived way to use it. It took me a=
while to get that through my head. In the end I agreed that it's superior t=
o use features like I described above than to burden H::T with indicators a=
bout what is essentially formatting (retention or removal).

Hope that helps.

Mark

Re: [htmltmpl] extra whitespace

[Chris B. <htm...@pa...>]

Rumour has it Mark A. Fuller, on or about 08.Feb.2006 16:30, whispered:
> I raised this issue a year or two ago and it wasn't well-received.
> It seems like it's common for newcomers (as I was) to spot this
> and believe it's a shortcoming in H::T.

Look, of course there are ways around it, with multiple levels of filtering,
pre- and post- processing.  This is Perl, after all, TIMTOWTDI.

I do not argue that H:T should be the be-all and end-all of frameworks and that
every single minor feature should be slopped in, but hat doesn't change the fact
that if a _lot_ of people come across the same issue with a framework and there
is a clear scenario that spans most people's use cases, then it makes sense to
do it in H:T.

H:T, in my view, is most useful to separate display from code.  Adding more
layers and wrappers of code to affect display is counter-productive.

Cheers,
Chris
--
Chris Beck  -  http://pacanukeha.blogspot.com
Clearly we living breathing citizens should have more rights than the legal
artifices called corporate entities. Our social contract is more important
to Democracy than their market place only model with its over reliance on
the metrics of the 90 day number and the bottom line. -- Jock Gill

Re: [htmltmpl] extra whitespace

[Alex T. <al...@ac...>]

On Wed, 8 Feb 2006 14:30:16 -0700 (GMT-07:00), Mark A. Fuller wrote
> I raised this issue a year or two ago and it wasn't well-received. 

Hi Mark,

   I completely agree that the filter option is an excellent feature, but I'm
not certain it is the right feature to use for stripping linefeeds. I am
dealing with the formatting of a lot of plain text in <pre> and <p> tags. In
most cases, there are linefeeds inbetween those tags that I don't want to
remove. While I *could* write code to handle that, that may not be the best
approach...
   I havn't looked into the H:T code too much, but I would imagine its doing
some sort of tokenizing of the template before switching out the TMPL tags.
Why go through the trouble of re-tokenizing the data in a filter to isolate
<p> and <pre> from getting stripped if its an option that could be more easily
added to H:T?
   I think the additional whitespace is also unexpected behavior. If I write:

<TMPL_IF QUANTITY>
<TMPL_VAR AMOUNT>
<TMPL_ELSE>
None
</TMPL_IF>

the output I expect is:

"None"

not:

"


None

"

Be flexible in what you accept and rigid in what you produce.

Alex

RE: [htmltmpl] extra whitespace

[Paulsen, B. <BPa...@le...>]

Wasn't there a push a while back to have a HTML::Template::Filter class
that would have commonly used filters=3F  =20

-----Original Message-----
=46rom: htm...@li...
[mailto:htm...@li...] On Behalf Of
Mark A. Fuller
Sent: Wednesday, February 08, 2006 4:30 PM
To: Alex Teslik; htm...@li...
Subject: Re: [htmltmpl] extra whitespace

=46rom: Alex Teslik <al...@ac...>
>Is there a switch (feature request=3F) that will tell HTMLTMPL to replace

>a TMPL followed by [\n\r]+ with nothing - even better replace the whole

>line if the only thing on the line is a TMPL tag=3F

I raised this issue a year or two ago and it wasn't well-received. It
seems like it's common for newcomers (as I was) to spot this and believe
it's a shortcoming in H::T. Among experienced users, they believe it's
easier and faster to use the "filter" option to strip *all* linefeeds if
wasted bandwidth is your motivation to remove some. If the performance
overhead of using the "filter" option is a concern, then preprocess your
templates to load, filter and output them to another file which will be
your template to be used at run-time.=20

I do this for other reasons, like if there is common processing to be
applied to parts of the page once. For example: international language
substitution of headings, labels, etc. I use tags prefixed as "PREPROC-"
in my *master* template to differentiate things that need to be
preprocessed versus the tags that are dynamically set at run time. I use
a batch script to load the template and "filter" the TMPL- tags to
"HOLD-" tags, change the "PREPROC-" tags to "TMPL-" tags. I don't strip
the linefeeds in this filter. I do my preprocessing to set TMPL-VARS and
LOOPS as necessary for one-time initialization of the page (for example,
language substitution). I output the H::T object to a variable and
perform a regex on the variable to change all the "HOLD-" tags to
"TMPL-" tags. This is where I strip the linefeeds. Then print this
variable to a file which will be the template used at runtime. So, I
have a master template (with includes, etc.) and a run-time template
that needs no run-time processing except the actual variables that can
change at run time (messages, dynamically generated lists, etc.).

That's probably a much more complicated example than what you need just
to strip linefeeds. The filter option will work for you. I just wanted
to demonstrate that there's a lot of ways to solve a problem with H::T
if you realize you're not stuck with just one preconceived way to use
it. It took me awhile to get that through my head. In the end I agreed
that it's superior to use features like I described above than to burden
H::T with indicators about what is essentially formatting (retention or
removal).

Hope that helps.

Mark


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
=66iles for problems=3F  Stop!  Download the new AJAX search engine that
makes searching your log files as easy as surfing the  web.  DOWNLOAD
SPLUNK!
http://sel.as-us.falkag.net/sel=3Fcmd=3Dk&kid=103432&bid#0486&dat=121642
_______________________________________________
Html-template-users mailing list
Htm...@li...
https://lists.sourceforge.net/lists/listinfo/html-template-users




---------------------------------------------------------------------------=
---
This message is intended only for the personal and confidential use of the =
designated recipient(s) named above.  If you are not the intended recipient=
 =
of this message you are hereby notified that any review, dissemination, =
distribution or copying of this message is strictly prohibited.  This =
communication is for information purposes only and should not be regarded a=
s=
 an offer to sell or as a solicitation of an offer to buy any financial =
product, an official confirmation of any transaction, or as an official =
statement of Lehman Brothers.  Email transmission cannot be guaranteed to b=
e=
 secure or error-free.  Therefore, we do not represent that this informatio=
n=
 is complete or accurate and it should not be relied upon as such.  All =
information is subject to change without notice.
----------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within =
this communication (including any attachments) is not intended or written t=
o=
 be used and cannot be used for the purpose of (i) avoiding U.S. tax relate=
d=
 penalties or (ii) promoting, marketing or recommending to another party an=
y=
 transaction or matter addressed herein.

Re: [htmltmpl] extra whitespace

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

From: Chris Beck <htm...@pa...>
>H:T, in my view, is most useful to separate display from code.  Adding more
>layers and wrappers of code to affect display is counter-productive.

I fully understand your argument because *I* made it a year or two ago. I feel like I'm arguing against myself. :) But, as someone said back then: white space in HTML is not "display". Viewing HTML is not "presentation." I ended up agreeing with that.

Adding a filter option will be a lot easier than trying to get H:T to remove linefeeds *that you inserted*. That was my conclusion after arguing the point a year or two ago.

Hope that helps,
Mark

Re: [htmltmpl] extra whitespace

[Chris B. <htm...@pa...>]

Rumour has it Mark A. Fuller, on or about 08.Feb.2006 17:46, whispered:
> But, as someone said back then: white space in HTML is not "display".
> Viewing HTML is not "presentation." I ended up agreeing with that.

Ah, I am not so sure.  It so happens that the HTML spec allows you to ignore
whitespace in many places, but that is just HTML.  And yeah, I know the product
is HTML::Template not Text::Template.  In MVC terms HTML::Template produces a
view that is reinterpreted as a model by the browser.

> Adding a filter option will be a lot easier than trying to get H:T
> to remove linefeeds *that you inserted*.

I'm not so sure of that.  In my view and I believe Alex as well, the end goal of
H:T is to have a framework that takes an easy to read and maintain template and
produces an easy to read and debug html page.  I personally try to avoid tmpl_if
statements for exactly this issue, but there are other devs on our team who have
no real choice.

Look, I don't want to spam people here, but you will have a hard time persuading
me that behaviour that seems intuitive is actually wrong.

In the meantime, I will keep using H:T because, as the kids say these days, it
teh r0xors.  Or something like that.

Cheers,
Chris
--
Chris Beck  -  http://pacanukeha.blogspot.com
"I don't think anybody anticipated the breach of the levees."
- President Bush, September 1, 2005

Re: [htmltmpl] extra whitespace

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

From: Alex Teslik <al...@ac...>
> I am dealing with the formatting of a lot of plain text in <pre> and <p> tags.

You can write a regex to remove whitespace only following TMPL_* tags. It doesn't have to remove *just* linefeeds or remove all linefeeds in the file. 

>   I think the additional whitespace is also unexpected behavior. ...

Expected behavior is a matter of learning how the tool works. On the one hand I agree with you that it seems intuitive that a TMPL_* tag standing on its own shouldn't leave a residual linefeed.  But, what if *I* want it to? Now the solution is to add an attribute to every TMPL_* tag indicating whether it should keep or delete a trailing linefeed? And, what if I prefer using spaces or tabs for readibility? Maybe I don't stack the tags on multiple lines, but use tabs or spaces to indent them? Why shouldn't H::T do the intuitive thing with those too?

The bottom line is: 

1) *You* added the whitespace. 
2) The whitespace doesn't affect the resulting HTML or its rendering. 
3) You work with the template, not the resulting HTML. The whitespace in the resulting HTML shouldn't affect anyone. 
4) Viewing the resulting HTML is not "rendering." 
5) If bandwidth is an issue, stripping *all* whitespace (for H::T tags and HTML tags) using the filter option is better than stripping just a few.

That was what was argued to me a year or two ago. I ended up accepting it as the correct way to look at the issue.

You can always wait for the Capital One guy (Sam) to come out and say "No." :) (In the US we have a commercial where Dana Carvey plays a credit card helddesk guy who's answer to everything is "No." Every time I see it I think of Sam.).

Mark

Re: [htmltmpl] extra whitespace

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

From: Chris Beck <htm...@pa...>
>and produces an easy to read and debug html page. 

I may not agree with this. If you're in the reading and debugging stage, don't use the filter option. If the whitespace (which you added to the template to make the template readable) interferes with your reading and debugging of the resulting HTML file, then use a modified filter that condences multiple line feeds to one. When it's running on the production server you can use a different filter (to strip all whitespace, including whitespace between HTML tags).

I agree that it seems obvious that an H::T tag standing by itself should'nt leave a residual linefeed. But, the filter works fine. And, it will be applied just once (beneficial to caching). I'd rather have H::T let me choose to do this one-time processing however I wish rather than do it form me when it outputs the template (which is where I assume it would happen if we expected it to drop linefeeds for standalone tags?).

I haven't found the filter option to be punitive.

Mark