in reply to RFC: Template::YetAnother

domm wrote: So, once again, code (even rather trivial) mixed with the markup.

With all due respect, I think you are misunderstanding something. While minimizing the amount of code in a template is a Good Thing, the benefit of templates is not separating code from the presentation. It's decoupling the application logic and the presentation logic. Consider the following Template Toolkit snippet:

[% IF people;
     FOREACH person = people %]
     <td>[% person.last_name %]</td>
     <td>[% person.first_name %]</td>
     <td>[% person.department %]</td>
[%   END; # FOREACH person;
   ELSE %]
    <td colspan="3" class="warning">No people found</td>
[% END; # end if %]

[download]

There's nothing wrong with that. We're not calculating overtime. We're not pulling department data from a database. In fact, we're doing nothing but controlling the presentation logic. By pushing the presentation logic back into the application, then the application needs to know how the data is to be presented. If later you need to change the presentation of the data, you're forced to change the application!

Of course, you could get around this by assembling your data and then passing it off to another portion of the code that knows about the presentation, but that portion of code is often referred to as a "template" :)

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil

Replies are listed 'Best First'.
Re: Re: RFC: Template::YetAnother
by domm (Chaplain) on Nov 16, 2002 at 15:57 UTC
    the benefit of templates is not separating code from the presentation. It's decoupling the application logic and the presentation logic.

    My problem with presentation logic vs application logic is where to draw the line.

    In your example, I would consider the warning about no people to be found to be part of the application logic. The template should just display this warning.

    In my proposed system, your example probably would look like this: 

    # in the App:
if ($sth->rows == 0) {
    $data->{'people'}=$th->people_none();
    return;
}
my @people;
while (my $r=$sth->fetchrow_hashref) {
    push(@people,$th->person($r);
}
$data->{'people'}=@people;
return;

# template people_none.tpl
<td colspan=3 class="warning">No people found</td>

# template person.tpl
<tr><td>[% last_name %]</td>
<td>[% first_name %]</td>
<td>[% department %]</td></tr>

    [download]

    By pushing the presentation logic back into the application, then the application needs to know how the data is to be presented. If later you need to change the presentation of the data, you're forced to change the application!

    The application doesn't need to know how the data is to be presented. It only needs to know what sort of data it is handling. The data then gets tagged (mis)using Perl's OO fetures (attributes would be another solution, I guess). The Templating System looks at those tags that describe data, chooses the appropriate template and fills in the data.

    One reason for starting to to think about my proposal was the problem of testing web applications. I asked Schwern about that on YAPC::EU 2002 and he said (more or less) one simple way to test Web Apps is to test the data each function/method returns before it gets passed to the template (So you do not have to parse the HTML in the test...)

    Until now I use a simple homegrown regex as a "templating system". It sucks. But none of the multitude of Templating Systems an CPAN really convinced me.

    But maybe I should take a much closer look at TT (which seems to be one of the better Templating Systems). I used TT a little bit when working on the mod_perl site and it definitly wasn't love at the first sight...

    Thanks for the feedback, anyway! 

    --
#!/usr/bin/perl
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

    [download]
[reply]
[d/l]
[select]

In Section Meditations