Consider: if the data generation and display reside in the same subroutine, you've restricted your development in two different ways: one, there's no easy way to reuse the code that generates the data for another purpose without a refactor. Second, a change to the code that outputs the data can possibly break the code that generates it.
Code that is decoupled into parts that generate data for someone else to consume, and parts that take data and display it, are now WAY easier to test as well. The generator code can be tested quite easily: call it, and is the right stuff returned. The display code can be tested by feeding it data which you have control of, verifying that the right thing is displayed.
So the separation vastly simplifies the process, which gives you more time to get things done, and makes it easier to be more adventurous in other places. For instance, all those building blocks can be used now to build a REST interface, simply by expanding different templates with the data they feed you.
In reply to Re: The hidden charm of Template::Toolkit (and templates generally)
by pemungkah
in thread The hidden charm of Template::Toolkit (and templates generally)
by roman
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |