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 ha

        • 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.)

      • I am convinced there's no such thing as a perfect separation of application and presentation logic.

        That said, we've done quite well with TT in Slash over the years.

  • Maybe it's time to start keeping code that does related stuff, you know, like grabbing from a database and prepping it for desplay, *together*! So when it needs to be tweaked, everything is close by not in 3 or more separate files?
  • I think you bring up an excellent point. I agree that OO can bring in complexity in the cases that you specify. But I would not write off OO in its entirety. I'm very interested in seeing what many other programmers think about this. Thanks -frank
  • You are talking about ravioli code [c2.com].

    • I think that node nicely illustrates what's going on here.

      Lots of insightful comments, as is usually the case with the c2 wiki.

  • A problem that I see is when OO is pushed to solve every problem.

  • One idea - OO makes it easier to cope with state - and this means people write more state-full apis where pure procedural languages would produce more stateless (functional) apis. And state is always more difficult to reason about.

    I don't want to single anything out - but what comes to mind is a hypothetical encoding API - that used to be of the form: my $encoded = encode( $from, $to, $what ); And then it became more OO with: my $encoding = Some::EncodingLib::new( $from, $to ); my $encoded = $encodi