in reply to Separation of Presentation and Application/Business Logic
in thread the trend of the presentation layer driving application logic

    Because templating systems are meant to remove all application/business logic and just focus on the appearance and presentation.

I disagree. While most business logic is contained elsewhere, there is still some logic in the presentation layer of the web application I am currently working on. It's along the lines of "If the current user has the privileges to do 'X', show the following link".

The graphic artist types don't need to concern themselves with any of that logic (if there were any on this project); they just need to know that the condition may be true, in which case a link may appear on the page.

--t. alex
Life is short: get busy!
  • Comment on Re: Separation of Presentation and Application/Business Logic

Replies are listed 'Best First'.
Re: Re: Separation of Presentation and Application/Business Logic
by robnagler (Novice) on Nov 04, 2003 at 21:58 UTC
    The graphic artist types don't need to concern themselves with any of that logic (if there were any on this project); they just need to know that the condition may be true, in which case a link may appear on the page.

    I agree, I think. This turns out to be tricky. Consider the following page:

    A | B | C
    where A, B, and C are conditional links, and the vertical bars are visual separators. It's actually tricky to code this in HTML where A might exist, but B might not, and C might. Or for some other arbitrary combination. We usually encode this in a widget, which tests whether A, B, or C are rendered (see below), and then fills in with a separator. In bOP, it might look like:
    NavBar(' | ', ['TASK_A', 'TASK_B', 'TASK_C']);
    The NavBar widget's render function would looks something like this (not tested :-):
    sub render { my($self, $source, $buffer) = @_; my($sep) = $self->render_attribute('separator'. $source); my($need_sep) = 0; foreach my $w (@{$self->get('values')}) { my($b); $self->unsafe_render_value($w, $source, \$b); $$buffer .= ($need_sep++ ? $sep : '') . $$b if $$b; } return; }
    This delegates the task of knowing how TASK_* is rendered to the widgets that know how to render tasks. In this case, it would be the Link() widget which looks up the permissions and the label based on the task name dynamically.

    The question I have is how would this look in other template languages. And, where do the labels come from? How are permissions determined? Who evaluates if the current user's role and the role's authorized permissions.

    That's where the "graphic designer" model breaks down. Either the designer has to know Perl to deal with the missing element problem, or the programmer has to work with the designer. There's no simple solution, but if the templating language doesn't offer ways to ask those questions (and most don't in my experience), you are left making things up as you go. That makes for funky websites where links lead to errors as opposed to using the meta data to ensure links don't get rendered unless you have the permission to execute them.

      Good points. For the particular issue you raise, I'd probably pass in an array of items and have the template figure out how to add the 'thing in the middle' in between items, doing The Right Thing if there are 0, 1 and more than one items.

      --t. alex
      Life is short: get busy!