NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Larry Wall in perl.c from the perl source code
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
TT vs Mason (Score:1)
You do an awful lot of hacking. Part of the Jifty philosophy is that we provide (at least) one well integrated way to do everything you need to do. We're big fans of HTML::Mason - it's the templating toolkit that best fits with our model of things - so it's the toolkit that's well integrated into Jifty. We'd love to hear suggestions about how to get TT or other templating engines to support the bits we need.
I think if you want TT support it will have to come from the Jifty community.
Why would you use TT over Mason? I use TT and have just looked briefly at Mason. Is TT better suited for a framework?
Reply to This
Re: (Score:2)
Don't get me wrong. Mason is great. It's fast, it's powerful, it's widely used and therefore widely known. The problem with Mason is that in just about every shop I've worked at, a lot of application logic seems to wind up in the Mason code. This is makes it harder to test and makes components harder to reuse, even if their dislpay properties are generic. Like a subroutine or a method, a template should try to do as little as possible, otherwise you limit your ability to reuse it. Even though Mason do
Re: (Score:1)
Those are good points and something to think about.
It wouldn't stop me from using Jifty either since it would be yet another framework I could learn using Perl. I tend to be on the "cleaner separation" side of things and I think TT does well in helping that mentality. Plus I think TT lends itself to other things besides web applications so I can use it more (but that may be wrong since I don't know Mason well enough).
Re: (Score:2)
Mason can be used for non-web stuff, but I've heard people say that it's tricky. I have no direct experience with this.
Another nice things about TT is that it's trivial to hande templates to designers. They don't have to learn Perl, just a simple template language. Here's another huge plus, and this alone should sway people:
Is "customer" a hash or an object? Who knows? Who cares? If initially you just pass a hashref and later decide you need to upgrade it to an ob
Re: TT vs Mason (Score:1)
The author point
Re: (Score:1)
I think the right way to allow that “natural” behaviour is to make it really, really easy to avoid Perl (unlike Mason), rather than making it really, really hard to use Perl (as TT2 prefers).
The only templating system I’ve ever seen that I really liked is unfortunately Python-only: Kid [lesscode.org]. It’s XML-centric, but it exploits that choice to do its job extraordinarily well: the majority of display logic is described declaratively using namespaced attributes. You need to reach down to Pyth