in reply to Re^3: Generation of dynamically-static documents
in thread Generation of dynamically-static documents

I'm trying to figure out how ttree or TT2Site is going to figure out what code to run as part of each template. For example, one page is a list of officers in the group. So, I need to query the officers "table" via DBD::CSV, ordered by a certain value. Another page is a list of activities, grouped by month. So I need to query the activities "table", ordered and grouped - and I need to figure out the current date and only get the activities in the current "activity year" (related to the school year - starts in September). Another page is a list of these activities with descriptions and the person who runs them, which is sometimes tied to the officers. So here's a query against a couple of tables.

These queries are already done, and they work. I just need to tie them in to the templates and either generate them statically or dynamically, depending on context. And I figured that with perl's great use of context, this would be a perfect fit ... somewhere. ;-)

And putting code of any sort into the template wasn't exactly what I was hoping for.

  • Comment on Re^4: Generation of dynamically-static documents

Replies are listed 'Best First'.
Re^5: Generation of dynamically-static documents
by CountZero (Bishop) on Sep 12, 2005 at 22:41 UTC
    It is very easy to use DBI and such from inside a TT2-template and if all else fails you can use pure Perl in the templates.

    CountZero

    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

      It is very easy to use DBI and such from inside a TT2-template and if all else fails you can use pure Perl in the templates.

      And that way lies madness :-)

      Throwing Perl code and direct DBI access into TT2 templates rapidly produces an unmaintainable mess in my experience.

        Yes, but it takes a genius to master chaos!

        Seriously, it is not much different from adding print-statements with HTML-code in your Perl-script.

        It would take something like Catalyst to keep all the various concerns nicely separate.

        CountZero

        "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Re^5: Generation of dynamically-static documents
by adrianh (Chancellor) on Sep 13, 2005 at 08:05 UTC
    And putting code of any sort into the template wasn't exactly what I was hoping for.

    Well, I don't consider putting presentational code near the templates as a sin :-) So, to pick one of your examples, if I was looking at a TT2 solution I'd package up a TT2 Officers plugin that wrapped up all the presentation aspects of the officers and then have a template that did something like:

    [% USE Officers %] ... <table> <tr> <th>Name</th> <th>Phone</th> </tr> [% FOREACH officer = Officers.by_name %] <tr> <td>[% officer.name %]</td> <td>[% officer.phone %]</td> </tr> {% END %] </table> ...

    So the [% USE Officers %] tells the template, and therefore ttree, what code needs running. I find something like this is often a nice solution. I'm providing a clean presentation object that can't be perverted into evil business logic in the templates, and the designers can go do presentational things with Officers wherever they like without me having to touch any more code.