Sharing templates will get you on the nice list
It was the night before Christmas Eve and the elves in Santa's Grotto were typing away on their keyboards getting ready for the tomorrow night, making sure the last minute issues were fixed. Unfortunately the day had started badly - the elves in the QA department had reported three bugs in quick succession with their website. If the elves didn't address the problems in the next few hours, Christmas would be ruined!
The QA elves had identified three problems with the website the team packing the sleigh use to record their work:
- If I filter with the widget the text is in suddenly in English, but if I hit reload it's Elvish as it should be!
- If I browse to the page it looks great, but if I refresh it goes bad!
- The total at the bottom of this table is wrong! Aren't there tests?
Pronto the Front End Develfoper
The leader of elvish front-end development team scratched her head for a moment. The first two seemed to be similar bugs, but in one case the "client side" was wrong and in the other the "server side" was wrong.
After much cross referencing between the two templating languages (and worrying about the minutiae of the different syntaxes) Pronto managed to commit a fix just a few hours before the deadline.
Sighing, Proto thought having to maintain two templating languages and two sets of identical templates is always going to be a huge pain for my team
Retro the Back-End Develfoper
Meanwhile the lead of back-end team looked for the source of the third and final bug, the table total bug. Her team grepped as hard as they could around
lib/SantasWorkshop/ but the table logic was nowhere to be found!
Finally, one of the team had a realisation - the logic wasn't in the modules, it was in one of the back-end templates themselves! And he was right, the addition - and the bug - was in the template file. Retro shook her head; no wonder there wasn't a test for it! Quickly she fixed the bug and pushed out a new release, but no-one in her team felt right about not being able to add a regression test for the code.
Sighing, Retro thought having all this logic in the templates where it can't be tested is always going to be a huge pain for my team
When Santa finally got back from his around the world dash, he scheduled debriefing meetings with his developers to learn about what could be improved for next year. When he heard all about the last minute problems that had nearly ended in worldwide disappointment for the children his forehead wrinkled under his big red hat. He sat quietly for a moment, stroking his mustache...
A smile crept across Santa's face. "Ho ho ho, I know of a solution to both your problems", he said, his grin widening. "Have you heard of Mustache?" The elves shook their head, but one of them brought up the website on his icePhone 6.
By being logic-less you're forced to put your logic into your Perl modules
where it's easy to write unit tests for your subroutines.
render them on the server side or the client side as needed.
Hogan.js and Text::Hogan
Despite the "logic-less" claim Mustache templates do provide some simple constructs you can use for optional blocks or looping blocks.
As you can see
# is used for ifs and loops, and
^ is used for negative checks. For more details see the mustache(5) man page.
One more issue
The elves had gleefully replaced all their old templates with new mustache based ones, and written tests for all their code that was previously locked away in template files. Hooray! But then one day, shortly before next Christmas, another bug report came in:
"I don't think we can use these new templates during the Christmas rush. Our metrics show that the site has gotten much slower since we switched."
Luckily one of the elvish development team was ready for this. Not wanting to fall into the trap of premature optimization he hadn't yet used one of hogan.js and Text::Hogan's most powerful features: pre-rendering.
compile method (like in the examples above) means you only compile a template to Perl code once per process (due to clever internal caching.) Using pre-rendering however, you can actually get at the generated Perl code and cache it somewhere on disk / in memcache, etc.
The Perl code that comes out the other end isn't pretty, but it renders really quickly:
Once the change to pre-compile the templates went live the site was even faster than it was on the old templates. Christmas was saved again!