I first downloaded Jifty a couple of days after it came out. It installed, but I couldn't get it to run. Last night I tried again and wrote up the experience on my Onlamp blog. It was pleased at how everything just worked, no assembly required.
Two things I want:
I know Mason, so I can live without the latter.
Of course there's a flipside to "it just works".
Or a caveat. It just works "if you do things
how they expect you to". I personally prefer
HTML::Mason over TT, so it's no problem
for me.
I've had an experience similar to yours. Tried it when it first came out, then put it on the "wait till it matures a bit" list. Maybe I'll take another look at it now. I thought that the "page regions" idea sounded really powerful, especially integrated with HTML::Mason components.
I'm particularly interested to see if they've added support for web services yet. They'd initially claimed that, but didn't in reality have it at all. I still haven't received a pony, either, though it's just as well since I don't really have room in my apartment for one.
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?
Re:TT vs Mason
Ovid on 2006-08-18T13:46:58
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 doesn't require you to do this, in the real world, this is what I keep seeing happening. This happens because much of the code seems to get developed on the Mason side and the developers slowly work towards the Perl.
With Template Toolkit, it's inverted. The development clearly starts on the Perl side and works its way out into the template. As a result, it's natural to not put the application logic in the view.
Now a standard rebuttal to this is "don't blame the tool because the programmer is misusing it" and I have a certain sympathy for that point of view. However, I like tools which allow the "natural" behavior to be the right behavior. This isn't enough of a complaint to keep me away from Jifty, though
:) Re:TT vs Mason
sigzero on 2006-08-18T13:55:50
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:TT vs Mason
Ovid on 2006-08-18T14:10:22
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:
[% name = customer.full_name %]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 object, TT will look for a "full_name" method before it tries to reach into the hash. As a result, you can often upgrade without any changes to your template code. This is a huge refactoring win.
Re: TT vs Mason
iburrell on 2006-08-20T02:14:55
I was reading about StringTemplate today. It is Java templating system (with C# and Python ports) that enforces the model-view separation and restricts putting code in the template. It takes static input data from the model and a functional template and generates output. The template language does not support assignment, side-effects, or procedural construct. It does allow some smart evaluation with JavaBeans objects or Java collections so it is possible to violate the encapsulation.The author pointed out that templating systems tended to divide into limited functional ones, or full-fledged Turing-complete programming languages. I am starting to think that if you are going to have a Turing-complete template language, it might as well be a real programming language. A more-limited Turing-complete language like TT may prevent mixing code from being less powerful but it still happens. Ruby works quite well with eRuby.
Re:TT vs Mason
Aristotle on 2006-08-21T01:12:04
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. 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 Python only when you’re actually doing something that falls outside the scope of “control flow.” Unfortunately, as I said, no Perl port exists. (It’s almost enough to get me to consider Python. Instead, I have been doodling a Perl port on and off for a while, as if I didn’t have enough unfinished projects.)
A big inspiration for that language was TAL, for which we do have several implementations on the CPAN, Petal probably being the most widely known. I am slowly converting over to that, because it’s the next best thing to massively messy imperative spaghetti TT2 templates, though it doesn’t do Perl (or any other language) in the template, instead inventing its own crippled expression minilanguage.
I am really tired of minilanguages.
In my old age I have lost all patience for the weird limitations of ad-hoc notations. Give me a real damn language or give me death.
