Re: The hidden charm of Template::Toolkit (and templates generally)

[pemungkah]

The separation of "creating the data" and "showing the data" is actually quite critical in providing a robust development environment for your application.

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.

[roman]

I agree. I don't have any problem to find reason for Model-View-Controller separation. The question regards solely the technology for the View component.

What is the advantage of template system not using Perl (Template::Toolkit) over templates using Perl for control structures, expanded expression, ... (HTML::Mason) over view component, which uses no templates just plain Perl code printing the HTML?

[graffitici]

The reason why it makes sense to use an entirely different language for the templates is quite simply to avoid using Perl. You may be very proficient in writing Perl code, but quite often the people who deal with the templates (and in general the 'View' part of the equation) are web designers. Those people are more likely to be better at HTML and CSS, and it therefore makes more sense to teach them how to use a simple template syntax (% s.name %) instead of teaching Perl (print $s{name}).

Even if all your web designers are Perl hackers, I think it still makes sense to learn a different templating language just for the sake of code clarity. I find it much easier to do all the hard work in my Perl in my Controller class, shove those variables in the stash (I use Catalyst), and then simply print and loop through the variables with the Template Toolkit.

All in all, TT is a very powerful system, and a language of its own. I once designed an entire web page that didn't need any "real" dynamic content, so I didn't have to write one line of Perl code: the whole thing was developed using Template toolkit and the ttree helper application.

[erik]

The reason why it makes sense to use an entirely different language for the templates is quite simply to avoid using Perl
If I may add to this... In one of my past projects, we used templates "of our own" to present data in tables and graphs. Because of short deadlines and heavy workload, we eventually had to fix some bugs here or there and because of the same-language commodity (as well as a few other reasons), we started mixing together the template code and the logics... ...which naturally impacted the development of future modules forcing me to save HTML tags with the data inside the database (yeah I know! that's a horrible thing that still gives me nightmares but I'll get over it eventually).

So I think it's really worth separating data and logic. And language isolation is also a good thing since it protects you from yourself.