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

Re: [htmltmpl] Whitespace (linefeed) suppression?

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

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

Re: [htmltmpl] Whitespace (linefeed) suppression?

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

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

Re: [htmltmpl] Whitespace (linefeed) suppression?

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

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

Re: [htmltmpl] Whitespace (linefeed) suppression?

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

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

Re: [htmltmpl] Whitespace (linefeed) suppression?

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

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.

;-)

Re: [htmltmpl] Whitespace (linefeed) suppression?

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

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

Re: [htmltmpl] Whitespace (linefeed) suppression?

[Keith J. <kja...@ey...>]

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

Re: [htmltmpl] Whitespace (linefeed) suppression?

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

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

Re: [htmltmpl] Whitespace (linefeed) suppression?

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

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

[htmltmpl] Whitespace (linefeed) suppression?

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

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

AW: [htmltmpl] Executing code after print $template->output

[<Seb...@3S...>]

> What about $|=3D1?

I tried that once (wanted to write a progress-bar for HTTP
uploads). But this will never work with mod_perl.

Ever had a look into Apache::UploadMeter? Oh my. Getting
just-in-time output in mod_perl is a whole lot of pain ;-)

If you just want to do some post-processing then the fork()
that Steve suggested seems to be most promissing.

By the way. The "mod_perl Programming" book says something like:
"... if you want to do time consuming operations which do not
result in HTML code sent to the browser you might want
to do this in a second Apache instance (without mod_perl) -- so
as not to waste mod_perl's precious resources ;-)
..."

Regards,
Sebastian

Re: [htmltmpl] Executing code after print $template->output

[Philip T. <phi...@gm...>]

Sometime on May 10, Sam Tregar assembled some asciibets to say:

> On Mon, 10 May 2004, Todd wrote:
>
> > Trying closing STDOUT after the call to output.
>
> You really don't want to do that in mod_perl...

What about $|=1?

-- 
'My strength is like the strength of ten because my heart is pure,' said Carrot.
'Really? Well, there's eleven of them.'
(Jingo)

Re: [htmltmpl] Re: [Comment] H::T => using <TMPL_UNLESS> to trigger <TMPL_LOOP>

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

On Sun, May 09, 2004 at 09:44:43AM -0500, Puneet Kishor wrote:
> since you asked for suggestions on improving the approach, my 
> suggestion would be to not use H-T/Perl for this at all. Use 
> JavaScript. I am assuming that you are using the cgi params to send 
> back in case errors are found because you are not using any db work for 
> error checking. If that is the case, check it _before_ the user submits 
> the form. 

  Never trust anything received from the browser.

  It's perfectly reasonable to use Javascript to deliver more
user-friendly error messages, but this should never be confused with
error *checking*.  (Unless, of course, you happen to enjoy reinstalling
your servers while reading an in-depth analysis of your program's bugs
and mockery of your personal competence on Bugtraq and the like.)

  All IMHO, of course.
  -- 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] Executing code after print $template->output

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

On Mon, 10 May 2004, Todd wrote:

> Trying closing STDOUT after the call to output.

You really don't want to do that in mod_perl...

-sam

[htmltmpl] ANNOUNCE: Krang v1.018 Released

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

Krang v1.018 is now available.  Notable changes in this release:

  - Krang will keep working if you to delete the 'admin' user.  A new
    hidden 'system' account is now used by automated tasks.

  - The permissions system is now applied throughout the UI.

  - The publish_check() method is working again after getting left
    behind in the Krang::Schedule rewrite.  This routine allows an
    element class to inhibit scheduled publishing.

  - Numerous bugs have been exterminated.

Detailed change-log here: http://krang.sf.net/docs/changelog.html

Krang is an Open Source web-publisher / content-management system
designed for large-scale magazine-style websites.  It is a 100% Perl
application using Apache/mod_perl and MySQL, as well as numerous CPAN
modules.

Krang provides a powerful and easy to use story and media editing
environment for magazine editors, as well as a complete template
development environment for web designers. On the back-end, Perl
programmers can customize Krang to control the data entered in the
story editor and add code to drive the templates to build output.
Krang can be enhanced with add-ons containing new skins and other new
features.  Krang easily handles large data sets and can manage
multiple websites in a single installation.

For more information about Krang, visit the Krang website:

  http://krang.sourceforge.net/

There you can download Krang, view screenshots, read documentation,
join our mailing-lists and access the CVS tree.

- the Krang team

Re: [htmltmpl] Executing code after print $template->output

[Todd <htm...@ch...>]

Trying closing STDOUT after the call to output.

-Todd

On Mon, May 10, 2004 at 05:38:45PM +0200, John wrote:
> Hi everyone
> 
> BACKGROUND
> 
> I'm using H::T with mod_perl and want to run some slow (several seconds)
> of code at the end of a script, and after the user receives his HTTP
> response.
> 
> I have tried doing the following:
> 
> print $template->output;
> $r->register_cleanup(\&some_stuff);
> 
> 
> sub some_stuff() {
> sleep 10; #for example
> }
> 
> Expecting to receive the template page while the sub routine
> "some_stuff" does its thing.
> 
> However, H:T seems to wait till "some_stuff" finishes before going to
> work.
> 
> AND NOW THE QUESTION(S)
> 
> So is there any way of getting H::T to get to work before the script
> calling the ->output method finishes ?
> 
> What exactly does H::T wait for before swapping the tags anyway ?
> 
> An alternative (and maybe off topic) question would be, if H::T must
> wait till the script calling the output method finishes before
> executing, does anyone know of a way to get the results I am looking for
> without forking ?
> 
> Cheers
> 
> John
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.680 / Virus Database: 442 - Release Date: 09/05/2004
>  
> 
> 
> 
> -------------------------------------------------------
> 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] Executing code after print $template->output

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

On Mon, 10 May 2004, John wrote:

> I have tried doing the following:
>
> print $template->output;
> $r->register_cleanup(\&some_stuff);

I don't know much about register_cleanup() but I have used
PerlCleanupHandler for this kind of thing with success.  Looking at
the docs for register_cleanup() it's not clear to me that it runs the
code after the response is sent to the client.  Just what is a "pool"
anyway?

> However, H:T seems to wait till "some_stuff" finishes before going to
> work.

I doubt it.  Try this to see if you're right:

  print $template->output;
  warn("HTML::Template output complete.");
  $r->register_cleanup(\&some_stuff);

If you get that warning in your logs before the sleep() starts then
HTML::Template is done and your problem lies elsewhere.  I suggest you
post a question to the mod_perl mailing-list where the mod_perl gurus
can give you a better answer than mine.

-sam

RE: [htmltmpl] Executing code after print $template->output

[Ragan, S. <sr...@bc...>]

The symptom you describe is not caused by H::T rather by the way the web
server 
process itself runs. If you want to do something time consuming after
displaying 
a web page you need to do some fork magic. Here's an example -


#!/opt/perl/bin/perl

$| = 1;
$ENV{'PATH'} = "/bin:/usr/bin:/usr/local/bin:/etc";
use strict;

my ($child, $grandchild);

unless ($child = fork) {
        # This is the child
        # close STDOUT and fork a grandchild to do the real work;
        close STDIN;
        close STDOUT;
        close STDERR;
        unless ($grandchild = fork) {
            # This is the grandchild
                open OUTFILE, ">>fork.log"  || die "Cannot open log file";
                my $date = `date`;
                print OUTFILE "Start: $date";
                sleep 20;
                $date = `date`;
                print OUTFILE "End  : $date";
                close OUTFILE;
                exit 0;
        }    # end grandchild UNLESS loop
        exit 0;
} else {
        ## This is the parent - Display Processing message ##
        print "Content-type:text/html\n\nParent leaving\n";
        waitpid $child, 0;
        exit 0;
}        # end child UNLESS loop


You print the output (the web page) in the parent and do the time wasting
stuff in 
the grandchild process. Works every time.

Steve

Steve Ragan
Sr. Internet Developer
Internet Services Division
Bernard C. Harris Publishing Co., Inc.
2500 Westchester Ave.
Purchase, NY  10577
(914) 641-3948
sr...@bc... <mailto:sr...@bc...>




-----Original Message-----
From: htm...@li...
[mailto:htm...@li...]On Behalf Of
John
Sent: Monday, May 10, 2004 11:39 AM
To: htm...@li...
Subject: [htmltmpl] Executing code after print $template->output


Hi everyone

BACKGROUND

I'm using H::T with mod_perl and want to run some slow (several seconds)
of code at the end of a script, and after the user receives his HTTP
response.

I have tried doing the following:

print $template->output;
$r->register_cleanup(\&some_stuff);


sub some_stuff() {
sleep 10; #for example
}

Expecting to receive the template page while the sub routine
"some_stuff" does its thing.

However, H:T seems to wait till "some_stuff" finishes before going to
work.

AND NOW THE QUESTION(S)

So is there any way of getting H::T to get to work before the script
calling the ->output method finishes ?

What exactly does H::T wait for before swapping the tags anyway ?

An alternative (and maybe off topic) question would be, if H::T must
wait till the script calling the output method finishes before
executing, does anyone know of a way to get the results I am looking for
without forking ?

Cheers

John

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.680 / Virus Database: 442 - Release Date: 09/05/2004
 



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

[htmltmpl] Executing code after print $template->output

[John <jo...@e-...>]

Hi everyone

BACKGROUND

I'm using H::T with mod_perl and want to run some slow (several seconds)
of code at the end of a script, and after the user receives his HTTP
response.

I have tried doing the following:

print $template->output;
$r->register_cleanup(\&some_stuff);


sub some_stuff() {
sleep 10; #for example
}

Expecting to receive the template page while the sub routine
"some_stuff" does its thing.

However, H:T seems to wait till "some_stuff" finishes before going to
work.

AND NOW THE QUESTION(S)

So is there any way of getting H::T to get to work before the script
calling the ->output method finishes ?

What exactly does H::T wait for before swapping the tags anyway ?

An alternative (and maybe off topic) question would be, if H::T must
wait till the script calling the output method finishes before
executing, does anyone know of a way to get the results I am looking for
without forking ?

Cheers

John

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.680 / Virus Database: 442 - Release Date: 09/05/2004
 

Re: [htmltmpl] Re: [Comment] H::T => using <TMPL_UNLESS> to trigger <TMPL_LOOP>

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

On Sun, 9 May 2004, Puneet Kishor wrote:

PK>since you asked for suggestions on improving the approach, my
PK>suggestion would be to not use H-T/Perl for this at all. Use
PK>JavaScript. I am assuming that you are using the cgi params to send
PK>back in case errors are found because you are not using any db work for
PK>error checking. If that is the case, check it _before_ the user submits
PK>the form. JavaScript is a great language with wonderful capabilities,
PK>and checking at the user end insures that you don't have unnecessary
PK>traffic at all. Of course, one argument would be "what if the user has
PK>js turned off...?" well, then.... don't use my suggestion.

I've said it before, and I'll say it again:  JavaScript is great for
PRE-submission checking, but the script can never, MUST never rely on it
to do final verification.  Even if you assume all the users you care about
use Javascript, you're also assuming that all the users who can submit
data are honest.

They're not.

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

[htmltmpl] warning_on_bad_params

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

Is there a way to get warnings on bad parameters ?

On one hand I set die_on_bad_params to 0 in order to avoid crashes
but I'd like to get the warnings in the error log.


Gabor

Re: [htmltmpl] Re: [Comment] H::T => using <TMPL_UNLESS> to trigger <TMPL_LOOP>

[Cees H. <ce...@si...>]

C Hagstrom wrote:
> 
> At any rate, what I ended up doing that appears
> to work was set the editing form up as an included file, and
> create a "parent" template up with this code:
> 
> <!--TMPL_IF NAME="intro_error_notice" -->
>         <!--TMPL_INCLUDE NAME=/path/to/template/edit_form.tmpl -->
> <!--TMPL_ELSE -->
>         <!--TMPL_LOOP EDITRES -->
>         <!--TMPL_INCLUDE NAME=/path/to/template/edit_form.tmpl -->
>         <!--/TMPL_LOOP EDITRES -->
> <!--/TMPL_IF-->
> 
> I digressed a bit, but I guess the short comment is that I was able
> to "switch" the <TMPL_LOOP> on or off using the code above.

Another way of handling this would be to still return the loop construct 
on the re-display, but only pass it an array with one hash in it.  This 
way you only get one entry displayed, and you can remove the extra 
complexity you have introduced in the example above.

> Hope I'm making sense here ... and there's probably much more
> elegant ways to do this, but the approach above appears to work
> at this point.

I don't know if many would consider this more elegant, but I am a 
believer that simplification is a form of elegance in coding.

Then again, I am also a firm believer in "if it ain't broke, don't fix 
it".  So if you have a working system, and you are happy with it, then 
leave it alone...

Cheers,

Cees

Re: [htmltmpl] Re: [Comment] H::T => using <TMPL_UNLESS> to trigger <TMPL_LOOP>

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

On May 9, 2004, at 9:25 AM, C Hagstrom wrote:

>
>> >No, but you're misunderstanding the tree structure. The entire
>> >loop.../loop needs to be within the unless.../unless.
>
> I think I understand that part of the structure ... what I was trying
> to do was call the template one of two ways ... the first
> using the loop functionality to populate the form, or the second,
> where it pulls in the cgi variables being passed to populate the form.
>
> In other words, I have an editing form for a DB record. When
> I first call the form, the script makes a DB call for a given record,
> stuffs the info from the record into an array, and then using
>  <TMPL_LOOP>  the template displays the populated form.
>
> After reviewing the info, making a change, and then "submitting"
> the form, I want the script to be able to perform error checking, and 
> if
> there is an unacceptable value being passed, I'd like to use
> the same form, but the fields would be populated with the
> cgi parameters just passed, and the error message displayed
> next to the field with the unacceptable value.
> ..
>
> That said, I'm up for any suggestions on improving the approach
>

since you asked for suggestions on improving the approach, my 
suggestion would be to not use H-T/Perl for this at all. Use 
JavaScript. I am assuming that you are using the cgi params to send 
back in case errors are found because you are not using any db work for 
error checking. If that is the case, check it _before_ the user submits 
the form. JavaScript is a great language with wonderful capabilities, 
and checking at the user end insures that you don't have unnecessary 
traffic at all. Of course, one argument would be "what if the user has 
js turned off...?" well, then.... don't use my suggestion.

[htmltmpl] Re: [Comment] H::T => using <TMPL_UNLESS> to trigger <TMPL_LOOP>

[C H. <hag...@ep...>]

> >No, but you're misunderstanding the tree structure. The entire
> >loop.../loop needs to be within the unless.../unless.

I think I understand that part of the structure ... what I was trying
to do was call the template one of two ways ... the first
using the loop functionality to populate the form, or the second,
where it pulls in the cgi variables being passed to populate the form.

In other words, I have an editing form for a DB record. When
I first call the form, the script makes a DB call for a given record,
stuffs the info from the record into an array, and then using
  <TMPL_LOOP>  the template displays the populated form.

After reviewing the info, making a change, and then "submitting"
the form, I want the script to be able to perform error checking, and if
there is an unacceptable value being passed, I'd like to use
the same form, but the fields would be populated with the
cgi parameters just passed, and the error message displayed
next to the field with the unacceptable value.

At any rate, what I ended up doing that appears
to work was set the editing form up as an included file, and
create a "parent" template up with this code:

<!--TMPL_IF NAME="intro_error_notice" -->
         <!--TMPL_INCLUDE NAME=/path/to/template/edit_form.tmpl -->
<!--TMPL_ELSE -->
         <!--TMPL_LOOP EDITRES -->
         <!--TMPL_INCLUDE NAME=/path/to/template/edit_form.tmpl -->
         <!--/TMPL_LOOP EDITRES -->
<!--/TMPL_IF-->

I digressed a bit, but I guess the short comment is that I was able
to "switch" the <TMPL_LOOP> on or off using the code above.

Hope I'm making sense here ... and there's probably much more
elegant ways to do this, but the approach above appears to work
at this point.

That said, I'm up for any suggestions on improving the approach

Carl Hagstrom


>Date: Sat, 8 May 2004 18:40:54 +0100
>From: Roger Burton West <ro...@fi...>
>To: htm...@li...
>Subject: Re: [htmltmpl] [Question] H::T => using <TMPL_UNLESS> to trigger 
><TMPL_LOOP>
>
>On Sat, May 08, 2004 at 10:59:00AM -0400, C Hagstrom wrote:
>
> >The value displays. So, I guess my question is, am I asking
> >H::T to do something it isn't able to do?
>
>No, but you're misunderstanding the tree structure. The entire
>loop.../loop needs to be within the unless.../unless.
>
>Roger
>
>


>Date: Sat, 08 May 2004 10:59:00 -0400
>To: htm...@li...
>From: C Hagstrom <hag...@ep...>
>Subject: [htmltmpl] [Question] H::T => using <TMPL_UNLESS> to trigger 
><TMPL_LOOP>
>
>Hoping someone can shed some light ...
>
>I have a template that calls a loop:
>
>
><!--TMPL_LOOP EDITRES -->
>
>Bunch of template HTML stuff here
>
><!--/TMPL_LOOP EDITRES -->
>
>And this works fine. What I'd like to do is
>use a conditional in the template so that the
>loop is only specified when a certain parameter
>is present on the script side ...
>
>
>
><!--TMPL_UNLESS NAME="intro_error_notice" -->
><!--TMPL_LOOP EDITRES -->
><!--/TMPL_UNLESS -->
>
>Bunch of template HTML stuff here
>
><!--TMPL_UNLESS NAME="intro_error_notice" -->
><!--/TMPL_LOOP EDITRES -->
><!--/TMPL_UNLESS -->
>
>But when I try this, I get the error:
>
>
>HTML::Template->new() : found <//TMPL_UNLESS>
>with no matching <TMPL_IF> at
>/path/to/template/file/here/template.tmpl : line 21.
>at /usr/lib/perl5/site_perl/5.6.1/HTML/Template.pm line 2117.
>
>
>I have confirmed that the conditional value is being passed ..
>if I use:
>
><!--TMPL_UNLESS NAME="intro_error_notice" -->
><h4><!--TMPL_VAR NAME=intro_error_notice --></h4>
><!--/TMPL_UNLESS -->
>
>The value displays. So, I guess my question is, am I asking
>H::T to do something it isn't able to do?
>
>
>Carl Hagstrom
>

Re: [htmltmpl] [Question] H::T => using <TMPL_UNLESS> to trigger <TMPL_LOOP>

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

On Sat, May 08, 2004 at 10:59:00AM -0400, C Hagstrom wrote:

>The value displays. So, I guess my question is, am I asking
>H::T to do something it isn't able to do?

No, but you're misunderstanding the tree structure. The entire
loop.../loop needs to be within the unless.../unless.

Roger