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

[htmltmpl] Is it possible to configure the eclipse wtp html editor to validate HTML::Template tags?

[Dietrich S. <die...@vi...>]

Hello List,

I'm currently working on a projekt which uses HTML::Template. As a 
development platform I use eclipse EPIC perl plugin and WTP.

Does anyone know a way to configure the html editor to ignore the 
HTML::Template tags without deactivating validation?
Or even better to allow the html editor to valdate the HTML::Template 
syntax?

Thank you for answering.

Best regards...

-- 
Mit freundlichen Grüßen
Dietrich Streifert
Visionet GmbH

Re: [htmltmpl] Possibility to include files "dynamicly"

[Michael P. <mp...@pl...>]

Maaged Mazyek wrote:
> Hello ppl,
> 
> in one of my templates i have a loop. On every pass, i want to include a
> different file.
> in short, i want to to something like this, but of course it does not
> work this way:
> 
> <TMPL_LOOP testloop>
> <TMPL_INCLUDE NAME="/path/to/foobar/<TMPL_VAR NAME="DOC_ID">.html">
> </TMPL_LOOP>
> 
> DOC_ID is every time different. My current solution is to do it with a
> php-include, but that just shifts the usage of the cpu to php.

You can't do it in the template, so you do need to shift the burden to someplace
else. But you can just do it in your Perl code that passes the variables to the
template.

In the code where you generate the data for the loop, create another template
object, pass in the same variables, get it's output and then use that output as
a var in your parent template.

-- 
Michael Peters
Developer
Plus Three, LP

[htmltmpl] Possibility to include files "dynamicly"

[Maaged M. <ma...@ma...>]

Hello ppl,

in one of my templates i have a loop. On every pass, i want to include a
different file.
in short, i want to to something like this, but of course it does not
work this way:

<TMPL_LOOP testloop>
<TMPL_INCLUDE NAME=3D"/path/to/foobar/<TMPL_VAR NAME=3D"DOC_ID">.html">
</TMPL_LOOP>

DOC_ID is every time different. My current solution is to do it with a
php-include, but that just shifts the usage of the cpu to php. And i
don't want to do this. There must be a way to solve it. I don't want
to install H:T:C just because of this feature.

thanks in advance,
regards,
Maaged

Re: [htmltmpl] Speeding up H::T

[Jim S. <js...@fo...>]

> Lastly, if you absolutely gotta have more speed, you could try
> HTML::Template::JIT.  It's got some drawbacks - not all of
> HTML::Template's syntax is supported and compilation times are long -
> but it is reliably 4 to 8 times faster.

You also might look into HTML::Template::Pro.  Its latest version is
current with HTML::Template version 2.8.

The author gives this description of the speed benefits:

HTML::Template::Pro loads, parse and outputs template on fly, when you
call $tmpl->output(), in one pass. The corresponding code is written in
C and glued to Perl using Perl+XS. As a result, comparing to
HTML::Template in ordinary calls, it runs 10-25 times faster. Comparing
to HTML::Template with all caching enabled under mod_perl, it still 1-3
times faster. At that HTML::Template caching requires considerable
amount of memory (per process, shareable, or on disk) to be permanently
filled with parsed trees, whereas HTML::Template::Pro don't consumes
memory for caches and use mmap() for reading templates on disk.

- Jim

Re: [htmltmpl] Speeding up H::T

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

On Tue, 27 Jun 2006, Matthew wrote:

>> Also, are you loading many templates and doing includes manually?
>> Switching to tmpl_include (which is processed at compile time) can be
>
> 	Not sure what you mean.

Some people do stuff like:

   my $header = HTML::Template->new(...);
   my $body   = HTML::Template->new(...);
   my $footer = HTML::Template->new(...);

   print $header->output, $body->output, $footer->output;

It's slower than just using tmpl_include.  I see it a lot so I thought
I'd mention it.

>     <TMPL_IF NAME="LOGIN_MENU">
>       <TMPL_INCLUDE NAME="login_menu.tpl">
>     </TMPL_IF>

This is a little strange, but I doubt it's a performance problem.
Usually each of those would be an indepenent template with:

   <tmpl_include header.tmpl>
   ... content stuff ...
   <tmpl_include footer.tmpl>

But I might be biased by using CGI::Application, which makes it really
easy for each run-mode (login_menu would be a CGI::App run-mode) to
have it's own template.

-sam

Re: [htmltmpl] Speeding up H::T

[Matthew <ma...@ma...>]

Sam,

> Are you pre-caching your templates in startup.pl?  There's a recipe

	Nope. I found the recipe and will try to incorporate that later this week.

> Also, are you loading many templates and doing includes manually?
> Switching to tmpl_include (which is processed at compile time) can be

	Not sure what you mean. Here is my object creation line, which is 
inside sub handler() ($template is a global var):

$template = new HTML::Template(
      filename => 'background.tpl',
      path => [ '/home/omnovia/public_html/pages/sctest/templates/' ],
      die_on_bad_params => 0,
      cache => 1
);

background.tpl contains this:

<TMPL_VAR NAME="HEADER">

   <TMPL_IF NAME="MESSAGEDIE">
     <TMPL_INCLUDE NAME="messagedie.tpl">
   <TMPL_ELSE>

     <TMPL_IF NAME="LOGIN_MENU">
       <TMPL_INCLUDE NAME="login_menu.tpl">
     </TMPL_IF>

     <TMPL_IF NAME="LOGIN_PAGE">
       <TMPL_INCLUDE NAME="login_page.tpl">
     </TMPL_IF>

     <TMPL_IF NAME="STRUCTURE_PAGE">
       <TMPL_INCLUDE NAME="structure.tpl">
     </TMPL_IF>

   </TMPL_IF>

<TMPL_VAR NAME="FOOTER">

in my code, if I need to display a certain sub-page, I just set one of 
the IF's above to 1 and parse the variables.  Is this the wrong way of 
doing this?

Thanks,
Matthew

Re: [htmltmpl] Speeding up H::T

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

On Mon, 26 Jun 2006, Matthew wrote:

>    I've already got "use HTML::Template" in my startup.pl so
> theoretically its being compiled at server start (anyway to verify
> this?). But its the instantiation in my handler() routine that's using
> the CPU time.
>
> How I can I get H:T to preform better?

Are you pre-caching your templates in startup.pl?  There's a recipe
for that in the HTML::Template docs.  After you do it, turn on
cache_debug and see if you're getting 100% cache hits (you should if
you did it right).

Also, are you loading many templates and doing includes manually?
Switching to tmpl_include (which is processed at compile time) can be
much faster.

Lastly, if you absolutely gotta have more speed, you could try
HTML::Template::JIT.  It's got some drawbacks - not all of
HTML::Template's syntax is supported and compilation times are long -
but it is reliably 4 to 8 times faster.

-sam

Re: [htmltmpl] HTML::Template::output() : Unknown item in parse_stack : HASH at /usr/local/share/perl/5.8.8/HTML/Template.pm line 2781

[Alexey M. <mel...@gm...>]

Thanx! We have just updated to 2.8 VERSION, hopefully it works out
"unknown item in parsed stack" error. I'll let you know if we still
have problems with this.

2006/6/9, Sam Tregar <sa...@tr...>:
> On Fri, 9 Jun 2006, Alexey Melezhik wrote:
>
> > HTML::Template INST_VERSION 2.6
>
> Please upgrade to 2.8.  I fixed a couple bugs that could cause this
> problem since 2.6.  If you can replicate the problem with 2.8 then
> please send me your template.
>
> Thanks!
>
> -sam
>


-- 
Alexey Melezhik

Re: [htmltmpl] Speeding up H::T

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

Hi Matthew,

Are you using 'global_vars', then H::T can be made to have a very
large speed up by replacing the code from lines 2624-2650 with:

  if (scalar(@{$options->{associate}})) {
    my @undef_params;
    foreach my $param (keys %{$self->{param_map}}) {
      next if (defined $self->param($param));
      push @undef_params, $param;
    }
    if (scalar(@undef_params)) {
      my $value;
      # if case sensitive mode or no CGI objects, we can use the
fast path
      if ($options->{case_sensitive} or (grep { !/^1/ } map {
UNIVERSAL::isa($_,'HTML::Template') } @{$options->{associate}}) == 0) {
        foreach my $param (@undef_params) {
          foreach my $associated_object (reverse
@{$options->{associate}}) {
            $value = $associated_object->param($param);
            next unless (defined $value);
            $self->param($param, scalar $value);
            last;
          }
        }
      } else {
        my %case_map;
        foreach my $associated_object (@{$options->{associate}}) {
          map { $case_map{$associated_object}{lc($_)} = $_ }
$associated_object->param();
        }
        my $associated_param;
        foreach my $param (@undef_params) {
          foreach my $associated_object (reverse
@{$options->{associate}}) {
            $associated_param = $case_map{$associated_object}{$param};
            next unless (defined $associated_param);
            $value = $associated_object->param($associated_param);
            next unless (defined $value);
            $self->param($param, scalar $value);
            last;
          }
        }
      }
    }
  }


Basically, the existing code is "loop intensive" - the replacement
code the big loops with smaller loops, thus the code runs faster.
In our app, this change resulted a 10x speedup in some specific cases.

Matthew wrote:
> Hey guys,
> 
>    Over the weekend, we (finally!) moved our company's primary web-app 
> from CGI over to mod_perl and incorporated H::T.  The funny thing is 
> that I started doing some speed comparisons using ApacheBench of our MP 
> version vs CGI.
> 
>     Short story is, both CGI and MP preformed about the same. In some 
> cases CGI was actually faster than MP. This bummed me out. I used 
> Apache::DProf to get an idea of what calls where taking the longest.
> 
>     Turns out that H::T takes at least 25% of the processing time each 
> time a MP request is made. Our CGI was using some in-house "template" 
> system. (ie: file open, search/replace line by line for variables, print 
> out).
> 
>     Like I said, this really bummed me out. For the longest time, CGI 
> was WAY faster than MP, until I turned on cache => 1 in H:T. That was a 
> HUGE improvement, but still CGI is slightly faster.
> 
>     I've already got "use HTML::Template" in my startup.pl so 
> theoretically its being compiled at server start (anyway to verify 
> this?). But its the instantiation in my handler() routine that's using 
> the CPU time.
> 
> How I can I get H:T to preform better?
> 
> Thanks,
> Matthew
> 
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

[htmltmpl] Speeding up H::T

[Matthew <ma...@ma...>]

Hey guys,

   Over the weekend, we (finally!) moved our company's primary web-app 
from CGI over to mod_perl and incorporated H::T.  The funny thing is 
that I started doing some speed comparisons using ApacheBench of our MP 
version vs CGI.

    Short story is, both CGI and MP preformed about the same. In some 
cases CGI was actually faster than MP. This bummed me out. I used 
Apache::DProf to get an idea of what calls where taking the longest.

    Turns out that H::T takes at least 25% of the processing time each 
time a MP request is made. Our CGI was using some in-house "template" 
system. (ie: file open, search/replace line by line for variables, print 
out).

    Like I said, this really bummed me out. For the longest time, CGI 
was WAY faster than MP, until I turned on cache => 1 in H:T. That was a 
HUGE improvement, but still CGI is slightly faster.

    I've already got "use HTML::Template" in my startup.pl so 
theoretically its being compiled at server start (anyway to verify 
this?). But its the instantiation in my handler() routine that's using 
the CPU time.

How I can I get H:T to preform better?

Thanks,
Matthew

[htmltmpl] Bricolage 1.10.2 "Summer" is Here

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

Fellow HTML::Templaters,

    The Bricolage development team is pleased to announce the release of
    Bricolage 1.10.2. This maintenance release adds a number of
    improvements and many bug fixes. Highlights include easier republishing
    of documents from the Find inteface and better-behaving textarea fields
    in Internet Explorer. The most important changes are:

 Improvements

      * The "codeselect" field's Perl code can now return an array of array
      references or a hash reference, in addition to the previous support
      for an even-sized array reference. [David]

      * Added a "Republish" checkbox and corresponding "Publish Checked"
      button to the Story and Media "Find" pages for stories and media not
      currently in workflow and to which the user has PUBLISH permission.
      Based on a patch from Serge Sozonoff. [David]

      * The number of items on a desk can now be displayed next to the
      desk's name in the navigation menu, e.g. "Edit (10)". This feature is
      configurable on a per-user basis via the new "Show Desk Asset Counts"
      preference. Based heavily on a patch from Alex Howarth. [Marshall]

      * Added a close icon to the drag bar of the dialog box. This is
      useful when the dialog box is bigger than the browser window and the
      close button therefore is off-screen. [David]

      * Aliases are now indicated in Find Stories by an arrow icon just
      before the story title. Suggested by Paul Orrock. [David]

      * Added PUBLISH_RELATED_FAIL_BEHAVIOR bricolage.conf directive to be
      used when PUBLISH_RELATED_ASSETS is enabled. If the automatic
      publication of a related story or media document will not be possible
      then the publish request will fail. It can be changed to "warn", the
      previous behaviour, if required. [Paul Orrock]

      * Added the "Remove Frameset" link to the control bar next to the
      "Repreview" link in the preview window. [Paul Orrock]

      * Slightly tweaked the background color on table rows to make them
      easier to read. [Marshall]

      * Object select lists (such as for story element types when creating
      a new story) will now display as scrolling lists if there are more
      than 50 items in the list, rather than 20 or more items. [David]

      * Added a CSS ID to the <body> tag in the UI, of the form
      "bricolage_VHOST_SERVER_NAME", where VHOST_SERVER_NAME is the value
      defined in bricolage.conf. Use this ID when writing user stylesheets
      to override the look of the Bricolage UI (see SkinningBricolage in
      the Wiki) [Marshall]

 Bug Fixes

      * Fixed warnings in deprecated methods of
      Bric::Biz::Element::Container so that they are no longer fatal.
      Reported by Nate Perry-Thistle. [David]

      * Fixed the "Search by Subelement" feature of story search. Thanks to
      Nate Perry-Thistle for the spot. [David]

      * The "Default Field" select list in Bulk Edit works again. Thanks to
      Tom Kjeldsen for uncovering the underlying problem. [David]

      * Fields that use the "codeselect" widget work again. Reported by
      Michael Glaesemann. [David]

      * Fixed the appearance of template diffs. Insertions and deletions
      now have color and no longer show underlines and strikethroughs (bug
      1171). [Marshall]

      * Fixed a bug where search results would get "stuck" when pagination
      is turned on. Thanks to Nate Perry-Thistle for the spot (bug 1166).
      [Marshall]

      * New users can once again be created when using the LDAP
      authentication engine. Reported by Christian Niles. [David]

      * Using Internet Explorer to create a media document via a the upload
      field in a related media element no longer uses a full Windows file
      system path. Reported by Tom Kjeldsen. [David]

      * Aliases are once again identifiable on desks by a different
      background color for the title, and now also with an arrow icon that
      appears just before the story title. [David]

      * Contributors are no longer sorted by the "Name Format" preference's
      representation of the contributors' names in the interface to edit
      contributor associations. They are now properly sorted by association
      order. Reported by Bret Dawson. [David]

      * The Help and logo popup buttons works again in Internet Explorer.
      Reported by Chris Heiland. [David]

      * Autosizing textarea fields now display full size in Internet
      Explorer when they have no content, instead of only 1 character wide.
      Reported by Paul Orrock. [David]

      * The Bulk Edit and template code textarea fields no longer jump
      around as you type in IE 6. [David]

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

    Download Bricolage 1.10.2 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, or from
    the Kineticode download page at
    http://www.kineticode.com/bricolage/downloads/.

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, PHP5, 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 has been hailed by eWEEK
    as "quite possibly the most capable enterprise-class open-source
    application available."

    Enjoy!

    --The Bricolage Team

[htmltmpl] ANN: Bricolage 1.8.1

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

Fellow HTML::Templaters,

    The Bricolage development team is pleased to announce the release of
    Bricolage 1.8.11. This maintenance release addresses a number of minor
    issues in Bricolage 1.8.10 and adds a few improvements, including a
    preview link for related media. Important bug fixes include:

      * My Workspace now remembers the sort order of assets just as well as
      desks do. [David]

      * Added more code to the inst/upgrade/1.8.9/fix_publish_status.pl
      upgrade script to better cover the possible variations in publish
      status inaccuracies. [Brad Fox, Brad Harder, & David]

      * Fixed media publishing so that when a media document is published
      to more than one output channel, and there are differences in the
      URIs for that media document between the output channels, that they
      won't trigger the expiration of each other's files. Reported by Rod
      Taylor. [David]

      * Fixed bug where users granted CREATE permission were unexpectedly
      allowed to PUBLISH items on the Publish Desk. [Christian Niles]

      * bric_queued now works with all burners, not just the Mason burner.
      Reported by Christian Niles. [Scott]

      * Changing an asset note and then going back to the notes screen
      before saving the asset now properly shows the changed note instead
      of the old note. Reported by Phillip Smith. [David]

      * New categories created via the SOAP interface with underscores in
      their URIs no longer end up with backslashes in the URIs. Reported by
      Ashlee Caul. [David]

    For the complete history of ongoing changes in Bricolage, see
    Bric::Changes at http://www.bricolage.cc/docs/api/1.8/Bric::Changes.

    Download Bricolage 1.8.11 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/downloads/.

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 has been hailed by eWEEK
    as "quite possibly the most capable enterprise-class open-source
    application available."

    Enjoy!

    --The Bricolage Team

Re: [htmltmpl] HTML::Template::output() : Unknown item in parse_stack : HASH at /usr/local/share/perl/5.8.8/HTML/Template.pm line 2781

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

On Fri, 9 Jun 2006, Alexey Melezhik wrote:

> HTML::Template INST_VERSION 2.6

Please upgrade to 2.8.  I fixed a couple bugs that could cause this
problem since 2.6.  If you can replicate the problem with 2.8 then
please send me your template.

Thanks!

-sam

Re: [htmltmpl] HTML::Template::output() : Unknown item in parse_stack : HASH at /usr/local/share/perl/5.8.8/HTML/Template.pm line 2781

[Jamie K. <jkr...@gm...>]

Can you put up or attach the template you're using?

Jamie

On 6/9/06, Alexey Melezhik <mel...@gm...> wrote:
> I can't fix it!
> ==================================================
> My options:
>
>
>         my $template = HTML::Template->new (
>
>
>              filename => $template_path,
>              path => $opt->{TMPL_ROOT_DIR},
>              die_on_bad_params => 0,
>              global_vars => 1,
>              loop_context_vars => 1,
>              cache => 1,
>               #            shared_cache => 1,
>               # ....
>
>           );
>
> We are under FAST CGI;
>
> HTML::Template INST_VERSION 2.6
> ==================================================
>
> Alexey Melezhik
>
>
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>

[htmltmpl] HTML::Template::output() : Unknown item in parse_stack : HASH at /usr/local/share/perl/5.8.8/HTML/Template.pm line 2781

[Alexey M. <mel...@gm...>]

I can't fix it!
==================================================
My options:


        my $template = HTML::Template->new (


             filename => $template_path,
             path => $opt->{TMPL_ROOT_DIR},
             die_on_bad_params => 0,
             global_vars => 1,
             loop_context_vars => 1,
             cache => 1,
              #            shared_cache => 1,
              # ....

          );

We are under FAST CGI;

HTML::Template INST_VERSION 2.6
==================================================

Alexey Melezhik

[htmltmpl] ANNOUNCE: Krang v2.005 Released

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

Krang v2.005 is now available.  Notable changes in this release and in
v2.004, which never received a proper announcement:

   * Added enforcement of permissions at the application and run-mode
     level rather than just at the UI level. [Michael Peters]

   * Fixed Xinha link-munging so that you can now use the WYSIWYG
     editor to create links and images.  Full-screen mode now works
     properly.  [Jesse Erlbaum]

   * Added a new configuration parameter, Charset.  This may be used to
     control the character set for the Krang user-interface.  [Sam]

   * Numerous improvements to the addon system. [Bodo Schulze]

   * Upgraded to HTML::Template::Expr v0.07, providing a better
     expression syntax and some bug-fixes. [Sam and Michael Peters]

   * Added new primitive, Krang::ElementClass::CheckBoxGroup,
     which integrates with Krang's lists system, in addition
     to permitting simple values.  [Jesse Erlbaum]

   * Added new option "--makecats" to krang_upload_media and
     krang_upload_templates.  When specified, missing categories will
     be created in the CMS.  [Jesse Erlbaum]

   * Many bugs are now fixed.

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 website 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] Parsing bug under Perl 5.6.1, and a fix

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

On Tue, 23 May 2006, Josh Clark wrote:

> Here's a strange bug that I encountered while running HTML::Template 2.8 
> under Perl 5.006001 (doesn't happen in the various flavors of 5.8 that I've 
> tried).

Sounds like a good reason to upgrade.

> The problem appears to be related to the uc function in line 1969:
>
>    $which = uc($1); # which tag is it
>
> Doing something with $1 (e.g. printing it or assigning it to a variable) 
> before calling the uc function fixes the problem.
>
>    $which = $1;
>    $which = uc($1); # which tag is it

I've seen this kind of Perl bug before in 5.6.x Perls when dealing
with UTF-8 data.  Are you intentionally doing UTF-8 work with Perl
5.6?  If not maybe you can force the data to be treated as plain
ascii, perhaps by playing with your LC_LANG setting.

-sam

[htmltmpl] Parsing bug under Perl 5.6.1, and a fix

[Josh C. <jos...@mi...>]

Here's a strange bug that I encountered while running HTML::Template  
2.8 under Perl 5.006001 (doesn't happen in the various flavors of 5.8  
that I've tried).

When using a scalar reference template, HTML::Template dies on the  
first TMPL_XXX tag that it encounters: "Unknown or unmatched TMPL  
construct at /fake/path/for/non/file/template"

I tweaked the error string to include the value of $which when it  
dies, and I discovered that the TMPL_ portion of the first tag was  
always replaced by F0B5, no matter what the original tag. For example:

TMPL_VAR     -->  F0B5VAR
TMPL_INCLUDE -->  F0B5INCLUDE
TMPL_IF      -->  F0B5IF
etc.

The problem appears to be related to the uc function in line 1969:

     $which = uc($1); # which tag is it

Doing something with $1 (e.g. printing it or assigning it to a  
variable) before calling the uc function fixes the problem.

     $which = $1;
     $which = uc($1); # which tag is it

After making that change, the problem goes away and the template  
string is parsed as usual.

All best,
Josh

Re: [htmltmpl] Small questions.

[Matias A. G. <ma...@ni...>]

On 5/18/06, Sam Tregar <sa...@tr...> wrote:
>
> On Thu, 18 May 2006, Matias Alejo Garcia wrote:
>
> > Maybe a good option would be to use 'memcached' (Cache::Memcached, whic=
h
> can
> > also be shared in the distributed environment, and is very easy to
> manage)
> > instead of IPC. What you think?
>
> Seems like a fun project, if possibly self-defeating.  I think it's
> unlikely that it would be faster than file_cache on a system with
> enough free memory to cache file-system access, but of course I could
> be wrong.


Thanks for your answer. We are setting an apache cluster in the next few
months, so maybe
we will evaluate that.

Stuff like this would be much easier to experiment with if I actually
> put out HTML::Template v3.  I'd like to split off the caching stuff
> into a separate plugable system.  Right now the cache-handling is in
> the core module and not terribly easy to extend.


That sounds great!

--=20
Mat=EDas Alejo Garc=EDa

NITS Argentina
    | http://www.nits.com.ar

Re: [htmltmpl] Small questions.

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

On Thu, 18 May 2006, Matias Alejo Garcia wrote:

> Maybe a good option would be to use 'memcached' (Cache::Memcached, which can
> also be shared in the distributed environment, and is very easy to manage)
> instead of IPC. What you think?

Seems like a fun project, if possibly self-defeating.  I think it's
unlikely that it would be faster than file_cache on a system with
enough free memory to cache file-system access, but of course I could
be wrong.

Stuff like this would be much easier to experiment with if I actually
put out HTML::Template v3.  I'd like to split off the caching stuff
into a separate plugable system.  Right now the cache-handling is in
the core module and not terribly easy to extend.

-sam

Re: [htmltmpl] Small questions.

[Matias A. G. <ma...@ni...>]

On 5/18/06, Sam Tregar <sa...@tr...> wrote:
>
> On Thu, 18 May 2006, Mathew Robertson wrote:
>
> > Shared cache has the nice effect of reducing the memory footprint of th=
e
> > templates, when running apache in multi-process mode.
>
> So does file_cache, and it's a heck of a lot easier to manage!



Maybe a good option would be to use 'memcached' (Cache::Memcached, which ca=
n
also be shared in the distributed environment, and is very easy to manage)
instead of IPC. What you think?



-sam
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronim=
o
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>



--=20
Mat=EDas Alejo Garc=EDa

NITS Argentina
    | http://www.nits.com.ar

UADE
    | Profesor Adjunto
    | Departamento de Inform=E1tica

Re: [htmltmpl] TMPL_SET -- this would be nice to have.

[Aleksandar P. <web...@te...>]

> Dear List,
>
> In most of my templates, I have a header and a footer templates that ge=
t
> included from the main template, which I assume is a very common
> scenario.  My problem is that <title> tag is in the header template and
> it needs to change for each template.  There are two approaches that I
> can currently use:
>
> 1. Put <title> tag into main template.  This works, but I do not believ=
e
>    having <title> outside of <head> is correct HTML[1].
>
> 2. Set title from CGI script.  This is not very convenient and, in my
>    mind, breaks the paradigm.
>
> The best solution, in my mind, would be something like this:
>
> ----  template search_results.tmpl  ----
> <TMPL_SET NAME=3D'TITLE' VALUE=3D'Search Results'>
> <!-- this is where title is used -->
> <TMPL_INCLUDE NAME=3D"_header.tmpl">
> <some_html_here>
> <TMPL_INCLUDE NAME=3D"_footer.tmpl">
> ----  end of template  ----
>
> Questions:
>
> 1. Is this feasible to implement?
> 2. Is such feature compatible with HTML::Template philosophy?
> 3. (Bonus question) is there another approach besides the two above tha=
t
>    I can use right now?
>
> Thank you,
>
>   - Dmitri.

1) Already answered - yes.

2) Not sure ...

3) Here it is:

<html>
<head>
<title> Whatever </title>
</head>
<body>
<TMPL_INCLUDE NAME=3D"_header.tmpl">
....
<TMPL_INCLUDE NAME=3D"_footer.tmpl">


Anyway, I walked the similar path when I needed some things added to the =
=20
HTML-Template
and many sugested TemplateToolkit ...

--=20
           Aleksandar Petrovi=C4=87
         Webmaster of Techcode.NET

Web:      http://www.techcode.net
Skype:    techcode.net
Yahoo:    johndoeyu
ICQ:      75863829
MSN:      joh...@ya...

Re: [htmltmpl] Small questions.

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

On Thu, 18 May 2006, Mathew Robertson wrote:

> Shared cache has the nice effect of reducing the memory footprint of the 
> templates, when running apache in multi-process mode.

So does file_cache, and it's a heck of a lot easier to manage!

-sam

Re: [htmltmpl] Small questions.

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

You can use a filter to strip stuff from your templates - check the list 
archive for examples

Mathew

> 2) Wouldn't be nice to have a template comment tag? 
> I think it would be useful to describe template, and not generate 
> HTML.  For example:
> <!-- <tmpl_comment>
>  This template shows a user. bla bla
>  Inputs:
>   - bla bla
> </tmpl_comment>
> -->
> or
>
> <!--
> # This template shows a user. bla bla
> # Inputs:
> #  - bla bla
> -->
>
> In our project we 'compile' the templates before installing to 
> production, so normal HTML comments are taken away, but I think that 
> the 'comment' tag would be interesting to have.
>

Re: [htmltmpl] Small questions.

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

Shared cache has the nice effect of reducing the memory footprint of the 
templates, when running apache in multi-process mode.

Mathew

> Yeesh - shared_cache is terrible.  I really should remove it.  It's
> no faster than file_cache and much more prone to problems.  Both are
> much slower than regular cache mode.
>
> -sam
>