Have dancer2 CLI understand different templates

[xsawyerx]

From Warren Young:

Long ago, I proposed that dancer2 be expanded to understand all of the available
template engines. The current version is hard-coded for Template::Toolkit, which
means playing with a different one means you have to understand both it *and* the
template engine you actually want to use, so you can translate the generated code.

This is less trivial than it sounds.  For instance, from views/layouts/main.tt:

  <meta charset="<% settings.charset %>">

needs to be changed to this for Xslate:

  <meta charset="<: $settings.charset :>”>

The obvious change is the bracket style, but how much user brainpower is wasted
figuring out that you need $ in the second case?  It threw me for a while, at least!

The fix is fundamentally simple: add something like “-t xslate” which selects a
different set of skeleton files.  Then all that’s needed is for someone to manually
translate the standard version for each template engine.

Incidentally, I notice that the initially hidden box underneath “About your
application’s environment” in the app generated by dancer2 is missing two values.
It looks like perl_version and settings.apphandler were defined in D1 but aren’t in
D2, but someone translated the code without checking for this regression.

[jasonblewis]

what about an approach similar to how localisation works? provide a list of template strings, and "translations" of those strings into other templating languages?

[cromedome]

My problem with this is adding unnecessary complexity to the CLI (I say this as I am frequently the one who adds unnecessary complexity to the CLI). If we do this:

dancer2 gen -a TestApp

we get an app skeleton with Template::Tiny, and if we do this:

dancer2 gen -a TestApp -t xslate

We'd get the xslate version. But not, we end up with a directory structure that looks like share/skel/tiny/, share/skel/xslate/, two sets of templates to maintain if we ever change the default app skeleton (which has happened recently - several times). In addition to tags and variable interpolation, we need to make sure to update the cpanfile for new template engines. None of these are insurmountable - merely annoying :)

Given a directory of skeletons, we already have code that lets you pass a name to use:

dancer2 gen -a TestApp -s /my/app/templates -n xslateapp

Might it be better just to use this, and if someone wants an app template for xslate, they can make one? I'd even be happy to include it in core. Open to comments :)

(I reread this and I suppose it's not that different from the original suggestion, just somewhat more generic)

[cromedome]

I'm going with the skeleton route for now and closing this. Change my mind or reopen this and we can revisit :-)