The fine line between control and display logic

[santonegro]

Straight from the reference manual for Template Toolkit, we see the following example for the IF directive:

[% IF age < 10 %]
       Hello [% name %], does your mother know you're 
       using her AOL account?
[% ELSIF age < 18 %]
       Sorry, you're not old enough to enter 
       (and too dumb to lie about your age)
[% ELSE %]
       Welcome [% name %].
[% END %]

Here we see variable output based on age and we see the use of display logic to handle it. But, a different way to think about solving this problem is to have a controller dispatch to 3 separate sub-actions, one for each age bracket, each of which points to a different view. Why would one go to this trouble? Because it scales to possible model actions later: logging each visit based on age, for example.

In Catalyst code, using control logic to handle age:

package MyApp::C::Login;

sub login : Path('/login') {
  my ( $self, $c ) = @_;

  my $age = $c->req->params->{age} ;
  if ($age < 10) {
    $c->forward('under10');
  } elsif ($age < 18) {
    $c->forward('under18');
  } else {
    $c->forward('welcome');
  }

sub under10 : Private {
 my ( $self, $c ) = @_;

 $c->model('Login')->incr_under10;
 $c->stash->{template} = 'under10.tt';

}

# and so forth

Now this might seem like overkill, but consider this more extensive example of a server database for Catalyst whose view is implemented in tt. Instead of two views, one for user and one for admin, we have a number of IF and UNLESS checks for admin interspersed in the code.

So, to summarize.

1. moving "display logic" from templates to controllers can make HTML more readable. The extensive example above could be refactored into two pages, one for admin and one for users and therefore be more readable.
2. moving "display logic" from templates to controllers insures scalability should additional model actions need to occur atomically with certain view actions.

[nothingmuch]

I agree with Anonymous Monk - that's a technical demonstration, not a style guide...

I would probably be inclined to have under10 and under18 in the same page, since they're probably similar, but keep welcome separate.

When too much display logic is in your controller your concerns are also mixed up - the controllers that handle logic (deciding on age) should not be concerned with the specific message that the page is displaying. It should be concerned with differences that are fundamentally different in their behavior. At least IMHO.

[phaylon]

I'd say that this is a rather bad example. And it seems it's used as an example for TT because it's just that, an example.

In this (pretty rare) case I'd suggest having a login validation action, and grant/deny access with a specified message (Too young, much too young). This message can then be displayed in the login template itself. So view logic is a clean and easy [% login_message %], and the back set's the reason into $c->stash->{ login_message }.

[LTjake]

You could probably argue back and forth ad nauseam as to how much or how little logic should go in the view. To me, the important thing is to strike a balance that results in a maintainable structure.

There are no definitive answers -- for which I'm glad, since it allows me/my workplace to set our own guidelines and create our own desirable structure.

[perrin]

I wouldn't send these to different templates, but I would move the comparison out of the template. I'd replace these age comparisons with booleans, and do the actual age checking in the controller.

[Anonymous Monk]

That TT example is not a demonstration of MVC.