in reply to Re^2: Output should have multiple segments
in thread Output should have multiple segments

I think a template model like Mason's could benefit from having multiple passes.

That's exactly where we differ. I think that a template system should only do the final pass - convert data structures to text.

Try to think about it this way: if your application has two different views (for example a Template::Toolkit one that produces HTML, and a Mason one that produces XML), how much many of these passes would be duplicate in these two views?

Let's say you have a web application that can produce both HTML pages and PDF files. In both cases you have a table of contents, and for each section you add to the output you also add a line to the table of contents.

If you do the logic for adding that TOC line (which essentially requires either two passes or two output segments) in the template, you duplicate your effort in the two different template systems.

OTOH if your perl code first assembles a data structure that represents the TOC, both of your templates just have to do their job: convert a data structure into text output. No more duplicate logic in there.

  • Comment on Re^3: Output should have multiple segments

Replies are listed 'Best First'.
Re^4: Output should have multiple segments
by Jenda (Abbot) on Jul 16, 2008 at 14:36 UTC

    Right. So instead of loading one subtemplate that receives the data structure I have to produce two datastructures (or often just remember which subtemplates will I want to use) and call two subtemplates. Lovely. Messy!

    Jenda
    Support Denmark!
    Defend the free world!

[reply]
      If the structure of your desired output requires two data structures, you create them.

      For me that's not a good reason for moving program logic into the template.

      If you're not convinced, think of what happens when you chose to add more views. There are plenty of possible output formats, like html, xml, pdf, json, yaml, plain text, ... - would you really want to duplicate code for all of those templates?

[reply]

        So it is a good reason for moving display logic into the controler, right? The fact that the HTML format requires that some part of the stuff produced by the template has to end up in the <head> is an HTML-specific implementation detail, not something that the controler needs or even should know about. Exactly because of the many possible output formats I should not polute the controler with stuff required by the implementation specifics of one of the output formats.

        Jenda
        Support Denmark!
        Defend the free world!

[reply]

In Section Meditations