The Template::Toolkit templates have a different syntax than the default Dancer templating system. You will have to rewrite the existing templates to use TT syntax ([% ... %]) or switch Template::Toolkit to use <% ... %> as syntax and then look at where the Dancer template system differs from TT.

Update: Just as I've posted this, I also read the same thing in Dancer::Template::TemplateToolkit. It seems you can even switch to <% ... %> syntax from within the config:

    template: template_toolkit
    engines:
        template_toolkit:
            start_tag: '[%'
            stop_tag: '%]'
[download]

Update 2: This is the documentation for Dancer, not Dancer2... For Dancer2, it's the other way around (Dancer2::Template::TemplateToolkit) :

  engines:
    template:
      template_toolkit:
        start_tag: '<%'
        end_tag:   '%>'
[download]

Thanks!

Also, I discovered I had turned on a different piece of config as well: the YAML session engine block at the bottom of the config.yml file.

It was that session engine block which was breaking things. As soon as I turned that off, the page worked again.

G'day v3ritas,

Welcome to the Monastery.

I was looking at a $work Dancer2 project this morning and recalled there was a question about this a few days ago. Here's some addional information.

$ cat config.yml
...
template: "template_toolkit"
engines:
    template:
        template_toolkit:
            START_TAG: '<%'
            END_TAG: '%>'
            PRE_CHOMP: 1
            COMPILE_EXT: '.tcc'
[download]

In brief:

• START_TAG and END_TAG are fairly self evident.
• PRE_CHOMP gets rid of lots of unwanted whitespace in the generated output.
• COMPILE_EXT caches templates.

For more detailed information on those, see Template::Manual::Config and "Dancer2::Template::TemplateToolkit - Template Caching".

Sounds like you have a good idea. I'll help review your proposed changes.



The way forward always starts with a minimal test.

 my $menu = popup_menu(-name=>'menu_name',
                         -values=>['eenie','meenie','minie'],
                         -default=>['meenie','minie'],
       -labels=>\%labels,
       -attributes=>\%attributes);

print $menu;
[download]

Using Template::Toolkit, create a template like this:

<select name="[% name %]" >
[%- FOR option IN options %]
<option [% FOREACH attr IN option.attributes.keys %][% attr %]="[% opt
+ion.attributes.$attr %]" [% END -%]
[%- IF option.default %]selected="selected" [% END -%]
value="[% option.value %]">[% option.label %]</option>
[%- END %]
</select>
[download]

In Dancer2 code, just call it with

return template 'menu',
    {name    => 'menu_name',
     options => [
         {value => 'eenie',  label => 'your first choice', attributes 
+=> {class => 'first choice'}},
         {value => 'meenie', label => 'your second choice', default =>
+ 1},
         {value => 'minie',  label => 'your third choice',  default =>
+ 1}],
     }
[download]

Update: Accept any attributes, not just class (not sure I'd recommend it).

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Thank you for your suggestion.

When I tried to encapsulate this code in a subroutine, and call it in another subroutine, Dancer2 seems to automatically use the main template located in the layout directory as a wrapper to this snippet, as well at to the entire page that generated an undesired visual effect. Ideally, it should be possible to write a simple subroutine that returns a menu, that, in turn can be invoked in some other subroutine that generates an arbitrary form:

 sub dropdown_menu { # should generate only an HTML snippet of a menu
  #my ..arguments..;

 return  template 'form_menu.tt', { ...argument hash...  };
}
.
.
.

get '/' => sub { # generates the actual form that is used as [% conten
+t %] in the layout/main.tt template

  template 'some_form.tt', {
      menu1  => dropdown_menu(...parameters1...),
      menu2  => dropdown_menu(...parameters2...),
      radio1 => radio_group(...parameters3...),
      .
      . 
  }
}
[download]

Does that make sense, or am I accidentally breaking some Dancer2 paradigm? I apologize if this question is trivial.

You have not mentioned Dancer2 at all, so I can only assume that part is irrelevant. In which case, here is my SSCCE:

#!/usr/bin/env perl
use strict;
use warnings;
use utf8;
use Template;

my $tt = Template->new;

my $name = 'François';

my $ttext = <<EOT;
As a literal: François

As an interpolated variable: $name

As a template variable: [% name %]
EOT

$tt->process (\$ttext, { name => $name });
[download]

---

🦛

Thank you for your quick response. Yes, I am investigating Dancer 2 to use as a replacement for the venerable CGI I've been using for many years. So my question is in context of Dancer 2. I am still in the early stages of familiarizing myself with it. Any suggestions would be greatly appreciated.

What encoding do you save the source code in? Do you use utf8 to tell Perl your source code uses UTF-8?
map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Thanks for your response. Yes I do. I think it might be something to do with interpolation.