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

Re: [htmltmpl] .tmpl page not rendering on screen

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

On Tue, 9 Nov 2004, Brad Cathey wrote:

> H::T is not returning any errors. Could it be a corrupt .tmpl file? If so,
> how would I know? 

What happens when you run it from the command-line?

-sam

[htmltmpl] ANNOUNCE: Bricolage 1.8.3

[David W. <da...@ki...>]

     The Bricolage development team is pleased to announce the release of
     Bricolage 1.8.3. This maintenance release addresses quite a large
     number of issues in Bricolage 1.8.2. The most important changes 
were to
     enhance Unicode support in Bricolage. Bricolage now internally 
handles
     all text content as UTF-8 strings, thus enabling templates to better
     control the manipulation of multibyte characters. Other changes 
include
     better performance for searches using the ANY() operators and more
     intelligent transaction handling for distribution jobs. Here are the
     other highlights of this release:

  Improvements

       * Added contrib/thumbnails/precreate-thumbs.pl script to 
pre-create
       thumbnails from images. Useful for upgraders. [Scott]

       * Added contrib/bric_import_contribs to import contributors from a
       tab-delimited file. Development by Kineticode, sponsored by the 
RAND
       Corporation. [David]

       * Added the published_version parameter to the list() methods of 
the
       story, media, and template classes. This parameter forces the 
search
       to return the versions of the assets as they were last published,
       rather than the most recent version. This will be most useful to
       those looking up other documents in templates and publishing 
them, as
       a way of avoiding pulling documents out from other anyone who 
might
       have them checked out! [David]

       * All publishing and distribution jobs are now executed in their 
own
       transactions when they are triggered by the user interface. This 
is
       to reduce the chances of a deadlock between long-running 
publishing
       transactions. [David]

       * Optimized SQL queries for key names or that order by string 
values
       to use indexes in the list() and list_ids() methods of the story,
       media, and template classes. [David]

       * Added Russian localization. [Sergey Samoilenko].

       * Changed the foreign keys in the story, media, and formatting
       (template) tables so that DELETEs do not cascade, but are 
restricted.
       This means that before deleting any source, element, site, 
workflow,
       or other related object that has a foreign key reference in an 
asset
       table, those rows must be deleted. Otherwise, PostgreSQL will 
throw
       an exception. Hopefully, this will put a stop to the mysterious 
but
       very rare disappearance of stories from Bricolage. [David]

       * A call to $burner->burn_another in a template that passes in a
       date/time string in the future now causes a publish job to be
       scheduled for that time, rather than immediate burning the 
document
       and then scheduling the distribution to take place in the future.
       Reported by Ashlee Caul. [David]

       * Changing the sort order of a list of items in a search interface
       now properly reverses the entire collection of object over the 
pages,
       rather than just the objects for the current page. Thanks to 
Marshall
       for the spot! [David]

  Bug Fixes

       * Publishing stories not in workflow via the SOAP server works 
again.
       [David]

       *

       * The Burner object's encoding attribute is now setable as well as
       readable. [David]

       * The category browser works again. [David]

       * Fixed Media Upload bug where the full local path was being 
used, by
       adding a 'winxp' key to Bric::Util::Trans::FS to account for an
       update to HTTP::BrowserDetect. [Mark Kennedy]

       * Instances of a required custom field in story elements is no 
longer
       required once it has been deleted from the element definition in 
the
       element manager. Reported by Rod Taylor. [David]

       * A false value passed to the checked_out parameter of the list() 
and
       list_ids() methods of the story, media, and template (formatting)
       classes now properly returns only objects or IDs for assets that 
are
       not checked out. [David]

       * The cover date select widget now works properly in the clone
       interface when a non-ISO style date preference is selected. 
Thanks to
       Susan G. for the spot! [David]

       * Sorting templates based on Asset Type (Element) no longer 
causes an
       error. [David]

       * Fixed a number of the callbacks in the story, media, and 
template
       profiles so that they didn't clear out the session before other
       callbacks were done with it. Most often seen as the error 'Can't 
call
       method "get_tiles" on an undefined value' in the media profile,
       especially with IE/Windows (for some unknown reason). Reported by 
Ed
       Stevenson. [David]

       * Fixed typo in clone page that caused all output channels to be
       listed rather than only those associated with the element itself.
       [Scott]

       * Fixed double listing of the "All" group in the group membership
       double list manager. [Christian Hauser]

       * Image buttons now correctly execute the onsubmit() method for 
forms
       that define an onsubmit attribute. This means that, among other
       things, changes to a group profile will persist when you click the
       "Permissions" button. [David]

       * Simple search now works when it is selected when the "Default
       Search" preference is set to "Advanced". Reported by Marshall 
Roch.
       [David]

       * Multiple alert types set up to trigger alerts for the same event
       will now all properly execute. Thanks to Christian Hauser for the
       spot! [David]

       * Publishing stories or media via SOAP with the published_only
       parameter (--published-only for bric_republish) now correctly
       republishes the published versions of documents even if the 
current
       version is in workflow. Reported by Adam Rinehart. [David]

       * Users granted a permission greater than READ to the members of 
the
       "All Users" group no longer get such permission to any members of 
the
       "Global Admins" group unless they have specifically been granted 
such
       permission to the members of the "Global Admins" group. Thanks to
       Marshall Roch for the spot! [David]

     For a complete list of the changes, see the changes list at
     http://www.bricolage.cc/news/announce/changes/bricolage-1.8.3/. For 
the
     complete history of ongoing changes in Bricolage, see Bric::Changes 
at
     http://www.bricolage.cc/docs/api/current/Bric::Changes.

     Download Bricolage 1.8.3 now from the Bricolage Website at
     http://www.bricolage.cc/downloads/, from the SourceForge download 
page
     at http://sourceforge.net/project/showfiles.php?group_id=34789, and
     from the Kineticode download page at
     http://www.kineticode.com/bricolage/index2.html.

ABOUT BRICOLAGE

     Bricolage is a full-featured, enterprise-class content management 
and
     publishing system. It offers a browser-based interface for ease-of 
use,
     a full-fledged templating system with complete HTML::Mason,
     HTML::Template, and Template Toolkit support for flexibility, and 
many
     other features. It operates in an Apache/mod_perl environment and 
uses
     the PostgreSQL RDBMS for its repository. A comprehensive,
     actively-developed open source CMS, Bricolage was hailed as "Most
     Impressive" in 2002 by eWeek.

     Enjoy!

     --The Bricolage Team

Re: [htmltmpl] .tmpl page not rendering on screen

[Offer K. <off...@gm...>]

On Tue, 09 Nov 2004 14:25:44 -0600, Brad Cathey wrote:
>
> Perl:
>
>    use HTML::Template;
>
>    my $template;
>
>    $template = HTML::Template->new(filename => '../admin/menu.tmpl');
>    $template -> param(facultylist=> $teacherdata );
>

Try setting die_on_bad_params to 0 and see what happens, e.g.:
$template = HTML::Template->new(
  filename => '../admin/menu.tmpl',
  die_on_bad_params => 0,
);

--
Offer Kaye

Re: [htmltmpl] .tmpl page not rendering on screen

[Brad C. <bra...@hi...>]

> On Tue, Nov 09, 2004 at 02:25:44PM -0600, Brad Cathey wrote:
>> Hello folks,
>> 
>> I've been using HTML::Template a thousand times over the past year and never
>> had a page just not output.
>> 
>> http://www.cicsnorthtown.org/cgi-bin/facultyadmin.pl?funct=menu
>> 
>> Check the source code and note it just renders "<html><body></body></html>"
>> 
>> If I try: http://www.cicsnorthtown.org/admin/menu.tmpl the page looks fine.
>> 
>> or, in my Perl if I substitute at different file, like "test.tmpl" it works
>> great.
>> 
>> 
>> Perl:
>> 
>>    use HTML::Template;
>> 
>>    my $template;
>> 
>>    $template = HTML::Template->new(filename => '../admin/menu.tmpl');
>>    $template -> param(facultylist=> $teacherdata );
>> 
>>    print "Content-type: text/html\n\n";
>>    print $template->output();
>> 
>> H::T is not returning any errors. Could it be a corrupt .tmpl file? If so,
>> how would I know?
> 
> My guess is you are getting some kind of fatal Perl error in the one
> invocation instance.  Try adding:
> 
> use CGI;
> use CGI::Carp 'fatalsToBrowser';
> 
> at the head of the program and see if you get any output with this.
> (This should send your Perl error messages to the browser, unless
> things are so messed up that Perl itself can't load.)
> -- Clifton

Thanks Clifton, but I have all that debugging stuff in place. In fact, when
I use Data::Dumper I it renders the page along with the hash.

I'd do a hex dump, but I have no idea what I'm looking for. Maybe I should
start rebuilding the .tmpl file line by line and see where it breaks.

BRad

Re: [htmltmpl] .tmpl page not rendering on screen

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

On Tue, Nov 09, 2004 at 02:25:44PM -0600, Brad Cathey wrote:
> Hello folks,
> 
> I've been using HTML::Template a thousand times over the past year and never
> had a page just not output.
> 
> http://www.cicsnorthtown.org/cgi-bin/facultyadmin.pl?funct=menu
> 
> Check the source code and note it just renders "<html><body></body></html>"
> 
> If I try: http://www.cicsnorthtown.org/admin/menu.tmpl the page looks fine.
> 
> or, in my Perl if I substitute at different file, like "test.tmpl" it works
> great.
> 
> 
> Perl:
> 
>    use HTML::Template;
> 
>    my $template;
> 
>    $template = HTML::Template->new(filename => '../admin/menu.tmpl');
>    $template -> param(facultylist=> $teacherdata );
> 
>    print "Content-type: text/html\n\n";
>    print $template->output();
> 
> H::T is not returning any errors. Could it be a corrupt .tmpl file? If so,
> how would I know? 

  My guess is you are getting some kind of fatal Perl error in the one
invocation instance.  Try adding:

  use CGI;
  use CGI::Carp 'fatalsToBrowser';

  at the head of the program and see if you get any output with this. 
(This should send your Perl error messages to the browser, unless
things are so messed up that Perl itself can't load.)
  -- 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] .tmpl page not rendering on screen

[Timm M. <tm...@ag...>]

At 02:25 PM 11/9/2004, Brad Cathey wrote:
>Hello folks,
>
>I've been using HTML::Template a thousand times over the past year and never
>had a page just not output.
>
>http://www.cicsnorthtown.org/cgi-bin/facultyadmin.pl?funct=menu
>
>Check the source code and note it just renders "<html><body></body></html>"
<snip>

Actually, it outputs nothing at all.  I bet you're using a Mozilla-based 
browser.  Mozilla puts in those HTML tags automatically when you view the 
source on an empty text/html document.

[htmltmpl] .tmpl page not rendering on screen

[Brad C. <bra...@hi...>]

Hello folks,

I've been using HTML::Template a thousand times over the past year and never
had a page just not output.

http://www.cicsnorthtown.org/cgi-bin/facultyadmin.pl?funct=menu

Check the source code and note it just renders "<html><body></body></html>"

If I try: http://www.cicsnorthtown.org/admin/menu.tmpl the page looks fine.

or, in my Perl if I substitute at different file, like "test.tmpl" it works
great.


Perl:

   use HTML::Template;

   my $template;

   $template = HTML::Template->new(filename => '../admin/menu.tmpl');
   $template -> param(facultylist=> $teacherdata );

   print "Content-type: text/html\n\n";
   print $template->output();


H::T is not returning any errors. Could it be a corrupt .tmpl file? If so,
how would I know? 

Thanks.

Re: [htmltmpl] RE: Patch to encode iso-8859-1 using HTML::Entities

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

> > I'd suggest that you dont do this...  Adding support for=20
> > ISO-8859-1 directly into H::T will set a precedent for other=20
> > encodings (not everyone uses the Latin character set)...
>=20
> Unfortunately, the precedent is that H::T generates broken,
> non-compliant HTML. The spec says that anything that's not
> 7 bit ASCII needs to be encoded. Latin1 is the common
> denominator.

Which spec says that anything other than 7bit ascii needs to be encoded? =
 I'm not sure that I understand which spec you are refereing to.

I understand that at minimum the a HTML document should specify the =
document encoding (or at least a META tag with the HEAD of the =
document).  If no encoding is specified, then the browser can assume =
that it is encoded in ISO-8859-1.


> > Why not just output the text as UTF8?
>=20
> The infrastructure we're building on supports Latin1, but
> not UTF-8. Fixing H::T to generate compliant bits is simple;
> reworking 20 person years of code to do UTF-8 isn't.


> Nothing in the patch precludes using other encodings.

Thats true, but if we add support for encoding to Latin, should we then =
do that for every other encoding?

regards,
Mathew

Re: [htmltmpl] RE: Patch to encode iso-8859-1 using HTML::Entities

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

I'd suggest that you dont do this...  Adding support for ISO-8859-1 =
directly into H::T will set a precedent for other encodings (not =
everyone uses the Latin character set)...

Why not just output the text as UTF8?

Mathew

----- Original Message -----=20
From: "Dave W. Smith" <dw...@da...>
To: <htm...@li...>
Sent: Saturday, November 06, 2004 5:26 PM
Subject: [htmltmpl] RE: Patch to encode iso-8859-1 using HTML::Entities


> One of my coworkers found and fixed an omission in the original patch
> whereby encode_entities wasn't getting propagated into TMPL_LOOPS. The
> revised patch is available here:
>=20
> http://www.dj-digit.com/work/HTML-Template-2.7-encode.patch
>=20
> We're planning to use this patch in production code.
>=20
> Dave
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=3D5588&alloc_id=3D12065&op=3Dclick
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
> 

[htmltmpl] RE: Patch to encode iso-8859-1 using HTML::Entities

[Dave W. S. <dw...@da...>]

One of my coworkers found and fixed an omission in the original patch
whereby encode_entities wasn't getting propagated into TMPL_LOOPS. The
revised patch is available here:

http://www.dj-digit.com/work/HTML-Template-2.7-encode.patch

We're planning to use this patch in production code.

Dave

Re: [htmltmpl] get value from template?

[Karen C. <kar...@gm...>]

On Wed, 3 Nov 2004 23:29:04 -0500, Bill Nixon <bn...@co...> wrote:
> I'm looking for suggestions on how to get a value from my template that can
> be used in my Perl code. I'd rather not switch to another template module
> that would provide this since HTML::Template has otherwise met my needs.

I've done something similar, but not with explicit SQL code.  Instead,
I've used TMPL_VAR names in a specific format:
"forum-getrootslast-cityhall-15" for instance, where "forum" is the
prefix that indicates it's a magic format, "getrootslast" is a
predefined SQL search, and "cityhall" and "15" are parms to be passed
to the search.

It's not quite as elegant as I'd like it to be, but it works for the
rare occasion I need it.

[htmltmpl] ANNOUNCE: Krang 1.026

[Peter L. <pe...@pe...>]

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

  * Support for Mac OSX has been added.

  * Support for Solaris has been added.

  * Support for Mandrake Linux has been added.

  * Krang data exports are now architecture-independant - moving Krang from
    x86 to SPARC or PPC is now supported.

  * New documentation aimed at developers using Krang.

  * Browser detection is fixed for Firefox 1.0 prereleases.

  * Added krang_extract_subset, making it possible to export a single site
    from a multi-site Krang instance.

  * Improvements to the find() methods allowing for multi-site searches of
    Stories, Media and Templates.

  * Numerous other small bugfixes and enhancements to Krang.

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.

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.


   - the Krang team

Re: [htmltmpl] get value from template?

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

On Wed, 3 Nov 2004, Bill Nixon wrote:

> In my template, I'd like to have something like:
> 
> <TMPL_VAR NAME="QUERY" VALUE="SELECT col1, col2 FROM table">

Why would you want to do this?  Are you really expecting your HTML
designers to know SQL?

-sam

Re: [htmltmpl] get value from template?

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

On Wed, Nov 03, 2004 at 11:29:04PM -0500, Bill Nixon wrote:

>2. extend HTML::Template to handle this via the existing TMPL_VAR or add a 
>new tag TMPL_DEFINE

That's what I did with my HTML::Template::Set extension. Contact me
directly if you want a copy.

R

Re: [htmltmpl] get value from template?

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

> I'm looking for suggestions on how to get a value from my template =
that can=20
> be used in my Perl code. I'd rather not switch to another template =
module=20
> that would provide this since HTML::Template has otherwise met my =
needs.
>=20
> The details...
>=20
> In my template, I'd like to have something like:
>=20
> <TMPL_VAR NAME=3D"QUERY" VALUE=3D"SELECT col1, col2 FROM table">
>=20
> and then do something like this in my Perl code:
>=20
> my $template =3D HTML::Template->new(filename =3D> 'test.tmpl');
> my $value =3D $template->param('QUERY');
>=20
> and have $value =3D "SELECT col1, col2 FROM table"

umm... why?  What benefit does this give you?  What kind of output are =
you expecting from the TMPL_VAR?

... its not clear how this requirement would be all that useful... or =
would even make sense in the context of "seperation of code and =
presentation" that H::T provides...

> My three thoughts are:
>=20
> 1. use a filter, but I don't know how to get $template instead of the =
filter=20
> subroutine so I can call $template->param to set the value. The only =
thing=20
> passed to the filter subroutine is the text of the file and not $self?
>=20
> 2. extend HTML::Template to handle this via the existing TMPL_VAR or =
add a=20
> new tag TMPL_DEFINE
>=20
> 3. Use HTML::Template::Expr, but my experience is that ::Expr is slow =
and I=20
> don't need all the other features it would provide.

Using H::T::E sounds like the best solution...

Mathew

[htmltmpl] get value from template?

[Bill N. <bn...@co...>]

I'm looking for suggestions on how to get a value from my template that can 
be used in my Perl code. I'd rather not switch to another template module 
that would provide this since HTML::Template has otherwise met my needs.

The details...

In my template, I'd like to have something like:

<TMPL_VAR NAME="QUERY" VALUE="SELECT col1, col2 FROM table">

and then do something like this in my Perl code:

my $template = HTML::Template->new(filename => 'test.tmpl');
my $value = $template->param('QUERY');

and have $value = "SELECT col1, col2 FROM table"

My three thoughts are:

1. use a filter, but I don't know how to get $template instead of the filter 
subroutine so I can call $template->param to set the value. The only thing 
passed to the filter subroutine is the text of the file and not $self?

2. extend HTML::Template to handle this via the existing TMPL_VAR or add a 
new tag TMPL_DEFINE

3. Use HTML::Template::Expr, but my experience is that ::Expr is slow and I 
don't need all the other features it would provide.

Comments on the above options or other thoughts on how to do this?

Thanks,
Bill

Re: [htmltmpl] Re: language support

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

On Fri, 29 Oct 2004, Peter Valdemar M=F8rch wrote:

> I use gettext, and so I've created this filter:
>=20
> my $gettextFilterSub =3D sub {
>  my ($text_ref) =3D @_;
>  $$text_ref =3D~
>  s/<gettext\(\"([^\"]*)\"\)>/gettext($1)/ge; # To satisify xgettext: "
> };

You could also use HTML::Template::Expr and setup a function called
gettext:

  <tmpl_var expr=3D"gettext('Hello World')">

It's more verbose but it will work better with the cache system.  If
you want your syntax you could combine the two:

 my $gettextFilterSub =3D sub {
  my ($text_ref) =3D @_;
  $$text_ref =3D~
  s/<(gettext\([^)]\))>/<tmpl_var expr=3D$1>/g;
 };

-sam

[htmltmpl] Re: language support

[<swp...@sn...>]

Martin Sarfy wrote:
>  	<TMPL_LANG lang=3D"eng">Hello</TMPL_LANG>
>  	<TMPL_LANG lang=3D"spa">Ciao</TMPL_LANG>
>  	<TMPL_LANG lang=3D"cze">Ahoj</TMPL_LANG>

The biggest problem with this, I find, is that if I use that solution
the template now needs to contain all the messages in all the languages
right there in the template. An update nightmare and quite messy.

Here is another suggestion:

I use gettext, and so I've created this filter:

my $gettextFilterSub =3D sub {
  my ($text_ref) =3D @_;
  $$text_ref =3D~
  s/<gettext\(\"([^\"]*)\"\)>/gettext($1)/ge; # To satisify xgettext: "
};

And then:
$template =3D HTML::Template->new(filename =3D> $tFile,
                                 filter =3D> $gettextFilterSub)

Now, I can just type strings that are subject to translation directly in=20
the template like:
<h1><gettext("My Project Title")></h1>
<gettext("Hello World")>

Using exactly the /<gettext\(\"([^\"]*)\"\)>/ format makes it possible
to use xgettext to extract the strings that need translation:

xgettext --c++ -o template.po template.tmpl

Now template.po contains entries for "My Project Title" and "Hello
World" that the translator can go right ahead and translate in a
separate file (completely standard GNU gettext and perl Locale::gettext
stuff ). If the translation is present it is used, otherwise the English
(or whatever) text is used.

I don't yet know how this works with caching, but I trust there is some
solution to that too... Cross that bridge when I get there... :-D

(I've just joined the mailing list and so I hope this ends up in the
right thread...)

Peter

P.S.: The magic I needed to get gettext to work was:
   ...
   # Or whatever language you like - We're in Denmark here...
   $ENV{LANG} =3D "da_DK";
   # I have a /tmp/da/LC_MESSAGES/proj.mo - created from .po with msgfmt
   bindtextdomain("proj","/tmp");
   # We can set the codeset explicitly or do so in a round-about way
   # using the LC_CTYPE...
   # setlocale(LC_CTYPE,"");
   bind_textdomain_codeset("proj", "ISO-8859-1");
   setlocale(LC_MESSAGES, "");
   textdomain("proj");
   ...
--=20
Peter Valdemar M=F8rch
http://www.morch.com

RE: [htmltmpl] Patch to encode iso-8859-1 using HTML::Entities

[Dave W. S. <dw...@da...>]

Alex Kapranoff writes:
> Could you please elaborate a little. Why do want all the 8bit 
> characters entities-encoded in the first place? It is 
> perfectly normal for HTML to contain latin1 characters if 
> there's a charset META or HTTP header (which you will need 
> regardless of whether you encode entities or not).

Unfortunately, browser support for charset isn't consistent,
particularly with older browsers. If we could throw all of
the old browsers overboard and make our customers all use the
current crop, live would be much simpler.

Dave

Re: [htmltmpl] Patch to encode iso-8859-1 using HTML::Entities

[Alex K. <ka...@ra...>]

Hi, Dave!

Could you please elaborate a little. Why do want all the 8bit
characters entities-encoded in the first place? It is perfectly normal
for HTML to contain latin1 characters if there's a charset META or HTTP
header (which you will need regardless of whether you encode entities
or not).

* Dave W. Smith <dw...@da...> [October 19 2004, 08:18]:
> We ran headlong into the need to add iso-8859-1 (Latin1) support to a large
> webapp that used over a hundred templates. Rather than tracking down the
> many places where we stuffed parameters, then modify them to use
> HTML::Entities (and remove "ESCAPE=HTML"), I took the "simplest thing that
> could possibly work" path, and added an 'encode_entities' option to new().
> When true, it causes 7-bit unclean characters to be escaped via
> HTML::Entities::encode_entities() when "ESCAPE=HTML" is used.
> 
> With the patch, getting most of the way to Latin1 support was a simple as
> adding
> 
>   my $template = HTML::Template->new(
>     filename => $template,
>     global_vars => 1,
>     cache => 1,
> +   encode_entities => 1,
>   );
> 
> 
> The performance hit (for the encode_entities => 1 case) is < 1% for our app,
> as measured via our unit test suite. 
> 
> The patch for HTML::Template 2.7, including doc changes and unit tests, is
> http://www.davewsmith.com/code/HTML-Template-2_7-encode.diff
> 
> To maintain backward compatibility for people who expect single-quotes to be
> escaped (e.g., for existing unit tests), single quotes are escaped either
> way.

-- 
Alex Kapranoff,
#!/usr/bin/perl -w
$SIG{__WARN__}=sub{print substr("@_",-43+ord$_,1)for
'6.823O1US90:350:739OJ;0:*'=~m}.}g},$}='PJlshrk';reset$}+43;

[htmltmpl] Patch to encode iso-8859-1 using HTML::Entities

[Dave W. S. <dw...@da...>]

We ran headlong into the need to add iso-8859-1 (Latin1) support to a =
large
webapp that used over a hundred templates. Rather than tracking down the
many places where we stuffed parameters, then modify them to use
HTML::Entities (and remove "ESCAPE=3DHTML"), I took the "simplest thing =
that
could possibly work" path, and added an 'encode_entities' option to =
new().
When true, it causes 7-bit unclean characters to be escaped via
HTML::Entities::encode_entities() when "ESCAPE=3DHTML" is used.

With the patch, getting most of the way to Latin1 support was a simple =
as
adding

  my $template =3D HTML::Template->new(
    filename =3D> $template,
    global_vars =3D> 1,
    cache =3D> 1,
+   encode_entities =3D> 1,
  );


The performance hit (for the encode_entities =3D> 1 case) is < 1% for =
our app,
as measured via our unit test suite.=20

The patch for HTML::Template 2.7, including doc changes and unit tests, =
is
http://www.davewsmith.com/code/HTML-Template-2_7-encode.diff

To maintain backward compatibility for people who expect single-quotes =
to be
escaped (e.g., for existing unit tests), single quotes are escaped =
either
way.

Dave

[htmltmpl] Re: H::Template and CGI::Application

[Mark S. <ma...@su...>]

On 2004-10-14, Daniel Axtell <dan...@sn...> wrote:
> Hello,
>
> I've been using HTML::Template for a while, but am having a weird problem when 
> using it in a CGI::Application app.  Basically, when I call 
> $template->output, the application requests the page from the server twice, 
> instead of once if I just create and return my own HMTL.

What do you mean by "the application requests the page from the server
twice". Isn't the application /on/ the server? Do you mean the run mode  
is getting called twice? What are you monitoring to know that something
is happening twice? 

This is indeed a strange issue, which doesn't immediately seem like a
problem in H::T or the 3 CGI::App systems you tried. I would double
check your application logic. If it still seems buggish, post a reduced
case of the troublesome code, along with notes about how you able to see
the duplicate request. 
	
	Mark

-- 
http://mark.stosberg.com/ 

Re: [htmltmpl] H::Template and CGI::Application

[Daniel A. <dan...@sn...>]

> a) run it under plain CGI (not mod_perl)
> does it have the same problem?
Yes.
>
> b) instead of
> 	 return $tmpl->output;
> 	do
>
> 	$tmpl->output;
> 	return "no output"
>
> does it print  "no output" now or the template + "no output"?

In both mod_perl and CGI, it prints "no output" only.  However, in both 
environments it's only bringing up the page once, not twice, the way it does 
when I do "return $tmpl->output" or "$self->page = $tmpl->output".  There's 
nothing in the HTML to force a refresh, and I'm not sending back an extra 
header that I can see.  Very strange.

[htmltmpl] H::Template and CGI::Application

[Thilo P. <thi...@we...>]

Hi,

> I've been using HTML::Template for a while, but am having a weird 
> problem when
> using it in a CGI::Application app.  Basically, when I call
> $template->output, the application requests the page from the server 
> twice,
> instead of once if I just create and return my own HMTL.

Not sure what is happing here, but can you try the following:

a) run it under plain CGI (not mod_perl)

does it have the same problem?

b) instead of

	 return $tmpl->output;

	do

	$tmpl->output;
	return "no output"

does it print  "no output" now or the template + "no output"?


Thilo

[htmltmpl] H::Template and CGI::Application

[Daniel A. <dan...@sn...>]

Hello,

I've been using HTML::Template for a while, but am having a weird problem when 
using it in a CGI::Application app.  Basically, when I call 
$template->output, the application requests the page from the server twice, 
instead of once if I just create and return my own HMTL.

CGI::Application is based around run modes, where calling 
http://localhost/myapp?rm=myrun  will send you to a method in a class derived 
from CGI::Application.  In the method I'm just getting some stuff from a 
database table, creating the template like this:

$self->load_tmpl($template_file, case_sensitive => 1);

and sending it back like this:
return $template->output; # for CGI::Application

or this:
$self->page = $template->output; # for CGI::Application::Plus

This is running under Apache 2.0.50 and mod_perl; HTML::Template 2.7; I've 
tried it under CGI::Application 1.30, CGI::Application::Plus 1.14, and 
CGI::Builder::CgiAppAPI v. 1.24  (all of these do basically the same thing).

If  I comment out the $template->output() call, the problem goes away: 
clicking on a like to the run-mode in question results in one call to that 
mode (but with no output); restoring the output() call results in two calls 
to the run mode.

I've been reading various man pages but I'm still baffled.  Anyone have an 
suggestions?

Thanks for any help,
Dan