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

Separation of data generation and view code is good, as you already have stated, so no need to discuss that.

Using a templating engine makes sense only if:

the non-perl/perl ratio is significantly higher than 0.5
the template can be rendered by its appropriate engine without template processing, and static / dynamic results don't differ significantly
the template can be edited with an appropriate editor for the given template language without placeholder or control constructs being dropped
you develop the views starting from static stuff which you "dynamise" later

Another reason could be wanting to have a visual distinction between model/controller and view code.

Using a non-perl templating language brings benefits only if you need to discipline yourself to use only a subset of what is possible in perl. As merlyn has put it -

It's not so much a restriction as merely a place where it starts getting interestingly harder.
I don't consider the edge-of-road markers that make a very loud noise in my car when I start to drift a "restriction" either. After all, I can ignore the noise, and keep driving off to the emergency shoulder, as I might need to do occasionally. However, it's a nice warning that I need to rethink what I'm doing.

So, if you have to "fight your tool" you either have a design flaw, or the tool is inappropriate for the task.

I don't buy the argument that

    $authors[$index]->{$book}->{title}
[download]

is less readable than

    authors.index.book.title
[download]

In the latter,no clue is given about what each token is; perl sigils actually increase readability.

It is not too hard to explain the meaning of sigils in perl. It is not too hard to explain what brackets and curlies mean. The sigils give a clue of what each token is, and it is a feature of perl we all love. Why not propagate that appreciation to non-perl coders?

Anyways, if "the html whackers" don't grok that, they shouldn't probably touch embedded code at all - be it perl or some other language.

The argument of "language independency" doesn't hold. What other languages implement e.g. Template's placeholder language? or that of HTML::Template ?

--shmem

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

Comment on Re: The hidden charm of Template::Toolkit (and templates generally) Select or Download Code

Replies are listed 'Best First'.

Re^2: The hidden charm of Template::Toolkit (and templates generally)
by exussum0 (Vicar) on Jan 07, 2008 at 13:20 UTC

It is not too hard to explain the meaning of sigils in perl. It is not too hard to explain what brackets and curlies mean. The sigils give a clue of what each token is, and it is a feature of perl we all love. Why not propagate that appreciation to non-perl coders?
Anyways, if "the html whackers" don't grok that, they shouldn't probably touch embedded code at all - be it perl or some other language.

Language dependency does hold. I hope you aren't writing arithmetic formulas in English. Hell, any formula would make my eyes bleed. :)

Update: Dear God shoot me for my inability to use English so early in the morn. Added a comma here, spelled dependency right there.... righting? oi!

[reply]


XP is just a number
	PerlMonks