Problems? Is your data what you think it is? | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
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:
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. 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
is less readable than
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
In reply to Re: The hidden charm of Template::Toolkit (and templates generally)
by shmem
|
|