Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • At least, the two places I've worked at that used TT (Socialtext and LiveText) both had gobs and gobs of logic in the templates. And TT's crippled language made dealing with this much harder than dealing with the same thing in Mason, since at least with Perl you have a sane language to use.

    People keep saying TT helps with this problem, but I have yet to see a good example of using it cleanly.

    • Re: (Score:2, Insightful)

      I agree that there are people who abuse TT by putting application logic in templates. But given enough rope, there will always some people who end up hanging themselves, or at best, tripping themselves up.

      TT's language is deliberately "crippled" because it's a presentation language, not a programming language. And the fact that TT makes it so trivially easy to write and use a plugin means that no-one should ever be doing "programming" using TT.

      But they do :-(

      However, that fact that some people don'

      • I think the TT has the fault lines at all the wrong places. Templates have three classes of complexity: static text (obviously a large part of the output); simple interpolation and undemanding logic (loops, conditionals; very common as well); and then hairy complicated formatting stuff with lots of little conditionals and munging and all sorts of wiry bits poking out of the data (common, but only in small amounts). The TT language is far more powerful than necessary for the simple logic but not enough to handle the complicated stuff well

        Trying to solve the problem in Perl is annoying because you must either break out of the templates and put the code in some other place within your application (and this is a layer of abstraction that most models don't conceive of, so it is organisatorially awkward to get the right idea for where it goes) or use PERL blocks which live in this weird limbo of being more like a TT dialect that is based on Perl, than being Perl. (You have no easy access to call other blocks like subs, you have to use the TT stash, etc -- it's not like writing normal Perl.)

        Let's not forget that templates are display logic, and the same concerns apply as to any other kind of logic: you should not repeat yourself etc. Display logic needs the same facilities for abstraction as business logic.

        So my conclusion is that the template language should be far less powerful than the TT language, leaving anything non-trivial to be handled by the host language through good integration (eg. exposing template blocks as easily callable methods from inside the host language or such), while making it extremely difficult to generate output directly from the host language side.

        Because the upshot is that any errant business logic that ends up in the template will still be somewhat decoupled from output generation, so that it can be factored out after the fact without too much pain. After all, let's be honest with ourselves: when time is at a premium, we all put business logic in the template with a FIXME and move on. Or sometimes we do not realise at the time that what we are writing is actually not a display concern. Better to plan ahead for what will inevitably happen and make it easy to recover from it, than try to prevent it.

        TT's design does not.

        (Mind, I might have come to disagree with its design, but I still admire its scope and execution; it's a tremendous piece of work.)

        • Display logic needs the same facilities for abstraction as business logic.

          Some days, it seems that only four people in the world understand this. (The third is Avi Bryant.)