Sorry for the slow & rushed reply.

Yes, HTML::Template can be a pain to work with - you're right that it doesn't
handle a hash of hashes.

This is something that needs fixing - can you raise an issue on Github at
http://github.com/bigpresh/Dancer-Template-HtmlTemplate/issues ?

I'm rather busy this week so probably won't have time to deal with it right
away.

Rather than hardcoding the param names to look at, I think I'd be inclined to

have it automatically flatten any hashrefs in the params into keys in the to
level hashref of params - so, for instance, if the params that were going to
be passed to HTML::Template looked like:

{
   foo => 1,
   bar => {
     baz => 2,
     bletch => 3,
   }
}

it would get "flattened" into, say,:

{
   foo => 1,
   bar.baz => 2,
   bar.bletch => 3,
}

Having to do that is nasty, but it's a limitation of HTML::Template which
doesn't let you dig into hashrefs, unlike for instance TT, where you can quite
happily use e.g. [% foo.bar %]

> 2) an alternate solution would be to make the creation of tokens a
> subroutine that a Template plugin can expose back to Dancer as an
> alternative way of serializing the tokens for the given Template engine.
>  *something like:
>
> $tokens ||= {};
> if (Dancer::Template->engine->can('create_default_tokens') ) {
>     $tokens = Dancer::Template->engine->create_default_tokens($tokens);
> } else {
> $tokens->{settings} = Dancer::Config->settings;
> $tokens->{request} = Dancer::SharedData->request;
> $tokens->{params} = Dancer::SharedData->request->params;
> if (setting('session')) {
> $tokens->{session} = Dancer::Session->get;
> }
> }

This might be a cleaner way, perhaps, but requires changes to Dancer's core
just to support this single template engine; on the other hand, it means
working around issues like this in future could be be easier.