in reply to Output should have multiple segments

IMHO the problems you describe are a symptom of wanting to do too much in the output layer (or template system, or "view" in the MVC model). Back in the old days I learned from a book that most programs are written in the "input - calculations - output" way, meaning first obtain all data, then do all the calculations, and only start to print them when you're all done. If you adhere to that, you don't have the problems you describe.

Mason seems to encourage doing very much work at the template level (or at least the tutorial I once read did), which is why I don't use it.

I also dislike it that in many catalyst tutorials some of the database queries are triggered in from the template.

I can't (yet?) really put my finger on it why it seems wrong, but it just plain feels wrong, and is the reason why I still stick to HTML::Template::Compiled, although it's not as nifty as, for example, Template::Toolkit.

Update: I thought more about why it feels wrong, and one thing that came to my mind is error handling. In Catalyst basically the controller does its work, creates a data structure (in the tutorials mostly DBIx::Class objects), and then hands off all the work to the controller.

But if the template accesses methods from these objects, they can trigger a DB query, which in turn could very well throw an error. But at this point it's too late for the controller to catch it in any meaningful way, since it already made all decisions it has to make.

The only remaining options are

All of them don't sound very convincing to me.

  • Comment on Re: Output should have multiple segments

Replies are listed 'Best First'.
Re^2: Output should have multiple segments
by Herkum (Parson) on Jul 16, 2008 at 00:15 UTC

    I agree with moritz don't use Mason. I am working at a company now that uses it and being able to insert Perl code anywhere anytime just makes for a horrible environment. It becomes too easy to lazy with design and just stick something in the template because it takes 5 minutes and a well designed, reusable tool will take 20.

    I refer to it as duct tape programming. Think of it this way, "I can fix correctly now, it will take me a while but I will not have to deal with it again" vs "I can put it together with duct tape and hope the next person to deal with it will not be me!"

[reply]
      Mason has a lot going for it. First of all, it uses Perl, not some new dinky language. Its architecture is sound, it is mature, and there are excellent documents on using it.

      When I first looked at ASP a good many years ago, that was my reaction too: mixing the code and data is bad, we should be separating it. It's awesome for just dropping in a value in the middle of a paragraph of HTML, and is really no different from how we interpolate in string literals.

      But I see that Mason has a few features so you are not forced to mix it to badly. If you decide to use "interpolation" in the same way as with Perl strings, and stick with pre-computed values in variables, and put real code elsewhere: The init section is solid Perl and computes all the needed values.

      For repeating lines, you can put a Perl loop around the HTML. In a specialized template notation that is all you could do, but here you could use any Perl any time. But don't. Stick to foreach loops on a % line.

      You can also call Mason components from normal Perl expressions, and are not forced to shift gears back and forth to do some computing, emit a component, and compute some more. You could even simply print ordinary Perl strings to the emitted output.

      —John

[reply]

        Mason is very flexible, the problem is that it is hard to make it follow a consistent structure. Anything you can do in Perl you can do in Mason, and that is the problem. A web page is about presentation. Once you start putting other stuff, like business logic, you are going to make it harder for to maintain and decrease portability with other applications. That is why I say avoid Mason, it is too easy to be lazy!

[reply]
Re^2: Output should have multiple segments
by John M. Dlugosz (Monsignor) on Jul 16, 2008 at 04:23 UTC
    I think a template model like Mason's could benefit from having multiple passes. That is, don't only have an output pass. First, just instantiate all the components that are being laid out or aggregated. Then do a compute pass on each one, where they all know about the complete page. Then do an output pass, which should gather and format results but not change anything.

[reply]
      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.

[reply]

        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]

      You should probably bring that up on the mason devel list. It would help (me at least, fwiw) also if you elaborated on the instantiate and compute phases.

      You might be able to do what you're talking about already with Mason's so-called object-oriented techniques. For example, for altering the attributes of the <body> tag you might use a method or attribute, which can be overridden by subcomponents.

[reply]
[d/l]

      That's how Mason works after all, but using a single output buffer. Ok, that's shallow, I hope the fellow masonites will forgive me for this one ;-)

      You should be able to quickly build yourself such a "multi-pass" system using your own conventions, following Mason's request cycle (briefly: gather output by running orderly each component in the inheritance chain)

      For the sake of example, here's a possible approach for such an autohandler:

      <%doc>
   # document everything (conventions, hacks etc) :P~
</%doc>
<%once>
   # load modules at this step only if you're not able to load them "a
+t startup"
   # (e.g. preloading them under a mod_perl enabled HTTPd)
   use My::App;
</%once>
<%init>
    # set up runtime/dynamic default configuration parameters
    $m->comp( '_conf', %ARGS );
    # ^ these should all be "notes" ($m->notes)

    # a <%shared> replacement (yeah, that's me,
    # I always avoided it for not doing what I meant) ;-/
    if ( $m->request_comp->method_exists('_init') ) {
        $m->request_comp->call_method('_init', %ARGS);
    }

    # fetch page content
    $m->notes( 'page_content' => $m->scomp( $m->fetch_next, %ARGS ) );
    # ^ remember that you have to *handle* the "exceptions"

    # <%cleanup> replacement
    if ( $m->request_comp->method_exists('_cleanup') ) {
        $m->request_comp->call_method( '_cleanup', %ARGS );
    }

    # render output
    return $m->comp( '_render', %ARGS );
</%init>

      [download]
      Also notice that you can optimize this by moving out more app. logic into your My::App modules ;-)

      --
      altblue.

[reply]
[d/l]
[select]

In Section Meditations