|
in reply to Model-View-Controller: Template Toolkit vs. XSLT
I mostly agree with Corion that all templating systems suck and that XSLT sucks even more. People should not be made to code in XML.
The thing I like the least about T::T is that it's slow and bulky - it's great if you want to make a lot of static files from complex templates, but IMO too slow for high-performance dynamic stuff. Also, having a complex templating system will probably bite you if you want to do MVC - programmers will tend to put too much logic in the templates, instead of in the model or controller classes. It's probably better to use a simpler templating system in this case.
As for the controller part, there are modules - most famously the Maypole system and CGI::Application. I personally think that Maypole is doing too much (like Template::Toolkit) and links to too many modules I don't like/want - I'd recommend CGI::Application, it's much simpler and runs anywere.
|
Re^2: Model-View-Controller: Template Toolkit vs. XSLT
by perrin (Chancellor) on Oct 14, 2004 at 23:58 UTC
|
TT is slow? Compared to what? The only benchmark I know of shows it running at about the same speed as other popular Perl templating tools: http://www.chamas.com/bench/ | [reply] |
|
|
Snails are still slow, even when you compare them to slugs.
What I dislike about TT isn't TT, but its fanboys. They claim that it allows you to seperate content from presentation from logic and that nothing else in perl does. What rot! Wanna display a table of data? You need logic in the template to loop over the data. Wanna display an arbitrarily sized table with arbitrary headings? You need a *lot* of logic in the template.
The fanboys also argue that TT is easy for non-programmers to use. Sorry, but my experience differs. I wrote some nice functional templates which worked, handed them over to a designer to make pretty (and bear in mind that TT is alledged to be designer-friendly), and he promptly broke them all.
Given that you can't get away from putting logic in the template, why bother inventing a whole new mini-language, when you could just use perl? The fanboys say that that means you put too much code in the template. Not true, unless you're an idiot. Perl has these things called "modules".
Having said all that, I do use TT. For *some* jobs, it's the right tool. For other jobs I use it grudgingly because it's the company standard and it at least has the advantage of being well known.
| [reply] |
|
|
My experience of introducing inexperienced programmers and Web developers to TT is that they find its dot notation easier to deal with than Perl's arrows and curly braces. The ambiguity caused by simpler syntax doesn't cause these people as many problems as the simplicity solves.
My experience with trying to explain logic to non-programmers fits yours: I had trouble explaining HTML::Template's TMPL_IF construct to one HTML designer. I think TT's syntax helps some junior programmers, though.
Your preference for using an existing language (Perl) over a mini-language (TT) fits the philosophy of Ruby's Rails project. I don't have a strong preference for either approach, but I think a separate templating system suits me better. As ever, choose the technology that suits not only the problem, but also the people who will solve it.
| [reply]
[d/l] |
|
|
The fact that a non-programmer could fail to use TT successfully does not mean that it isn't easy for non-programmers to use TT. It means that it is possible for non-programmers to mess TT up.
I talked about this in Re (tilly) 6: Code Critique. The problem is fundamentally an issue of figuring out how you'll cooperate. If you just threw a bunch of templates over the wall to the designer, I'd expect a bad result. If the necessary communication and understandings were worked out for cooperation to happen succesfully, good results are possible (and many people have achieved them).
| [reply] |
|
|
Snails are still slow, even when you compare them to slugs.
I don't agree with this. Speed is relative, and snails are only slow if you have something else much faster to compare them to, like a jet engine. Embperl and Apache::ASP are arguably significantly faster, but not a lot faster. Raw print statements are a lot faster, but sacrifice most of the functionality that leads people to a templating system in the first place.
Regarding the code for handling tables in a template, this is what plugins are for: you write the tricky part in Perl, and the template author still gets to control things like how many columns there are. A good HTML coder should be able to deal with simple loops and conditionals. I used the table plugin and date plugin successfully for this kind of thing.
Of course you could also write a module for this and use it from Mason or Apache::ASP, but I find that people don't usually do that when it's so easy to put the perl code right in the template.
Not every HTML coder in the world can handle templating. I've had nothing but success with TT, but I can imagine some people just won't get it. The key things that I did that helped were to provide documentation of the data being passed in (as oppposed to handing them sample templates to pretty up) and to give them a simple template tester that allowed them to type in test data (in the format that the real app would send) and run it through a TT template. This let them experiment easily.
| [reply] |
Re^2: Model-View-Controller: Template Toolkit vs. XSLT
by DrHyde (Prior) on Oct 15, 2004 at 08:37 UTC
|
I've never seen the point of CGI::Application. What, exactly, does it do that a giant if/elsif/else statement doesn't? Nothing, from what I can tell, aside from introducing another dependency, like what you criticise Maypole for. | [reply] |
|
|
| [reply] |
|
|
CGI::Application does many other things than "a giant if/elsif/else statement"
-- and it doesn't even really do that. (It implements a hash-based dispatch
table that maps a query string to a method; if no match is found, it uses a
default as specified.)
What does CGI::Application do?
- It provides a framework for developing re-usable,
customizable application classes. Simply use the class, pass some
metadata (in the form of a hash) to the constructor, and run() it
- It provides a sane framework for developing applications; each
screen gets a run mode, and each run mode gets a method --
CGI::Application-based classes are incredibly consistent and easy to
debug because it's easy to determine what piece of code is executed
when (look at the dispatch table instead of trying to scan through "a giant
if/elsif/else statement").
- It provides a means for wrapping a number of applications under a
site-umbrella, through it's various cgiapp_*() hook methods. Using these,
you can create a superclass that does security checks, places final
application content in a sitewide template, and creates customized
navigation and sidebars -- but still retain the flexibility of developing
only a single application suite at a time.
If used correctly, CGI::Application can be used as a very good Controller for an
MVC setup -- have it simply do the work of validating and sanitizing input,
passing it to the Model, and piping the Model's return values to the View (a
templating system).
What I like most about it is that, at it's core, it's a very slim piece of code
that simply stays the heck out of my way as I build my applications -- no
extraneous doodads or geegaws are loaded unless I specifically do so myself.
Yes, it's another dependency, but it has very little overhead and benefits that
outweigh the dependency a thousandfold.
| [reply] |
|
|
