MVC Views: Display Logic?

Question

I've been reading this paper: Enforcing Strict Model-View Separation in Template Engines (PDF).

It contends that you only need four constructs within the views:

1. attribute reference
2. conditional template inclusion based upon presence/absence of an attribute
3. recursive template references
4. template application to a multi-valued attribute similar to lambda functions and LISP’s map operator

No other logic is allowed within the view - for example if (attr < 5) would not be allowed, only if (valueLessThanFive)

Is this reasonable? Most MVC frameworks allow any logic within the views, which can lead to business logic creeping into the view. But is it really possible to get by with only those four constructs?

For "zebra striped" tables, the paper suggests mapping a list of templates onto the list of data - for example:

map(myList, [oddRowTemplate, evenRowTemplate])

But what if you want to make the first and last rows different styles? What if the 3rd row should be purple on Tuesdays because your graphic designer is mad? These are view-specific (for example if I was outputting the same data as XML I wouldn't use them) so don't seem to belong in the model or controller.

In summary:

• Do you need logic above the four constructs listed above within views?
  • If so, how do you restrict business logic creeping in?
  • If not, how would you make the 3rd row purple on Tuesdays?

Answer 1

Terence Parr is a very smart guy and his paper has much to commend it, but from a practical point of view I have found using just these constructs somewhat limiting.

It is difficult to prevent business logic creeping in especially if you have the ability to do anything, as for example ASP.NET and JSP would give you. It boils down to how you spend your time:

1. Allow limited additional functionality (I'm not an advocate for "anything goes") and use code review mechanisms to ensure correct usage, or
2. Restrict to the four constructs above, and spend more time providing attributes like valueLessThanFive (remembering to rename it to valueLessThanSix when the business requirement changes, or adding valueMoreThanThree - it's a bit facetious as an example but I think you'll know what I'm getting at).

In practice, I find that allowing conditionals and looping constructs is beneficial, as is allowing property traversal such as attr[index].value in template expressions. That allows presentational logic to be effectively managed, while incurring only a small risk of misuse.

Allowing more functionality such as arbitrary method calls gets progressively more "dangerous" (in terms of facilitating misuse). It comes down, to some extent, to the development culture in place in your environment, the development processes, and the level of skill and experience in your team.

Another factor is whether, in your environment, you have the luxury of enforcing strict separation of work between presentation and logic, in terms of having dedicated non-programmer designers who would be fazed by advanced constructs in the template. In that event, you would likely be better off with the more restricted template functionality.

Answer 2

To answer your question about the 3rd row purple on Tuesdays:

The original (or one of the very early) MVC patterns had the 'View' being a data-view, there was no concept of a UI in the pattern. Modern versions of the MVC pattern have felt the need for this data-view which is why we have things like MVVM, MVP, even MV-poo. Once you can create a 'view' of your data that's specific to the UI View it's easier to solve lots of the concerns.

In our case our 'model' is going to get extra properties on it, such as Style or Colour (style is better as it still lets the view define how that style is represented). The controller will take raw 'model' items and present to the view custom 'model' items with this extra Style, giving the 3rd row on Tuesdays a style of 'MadDesignerSpecial', which the view uses to apply the purple colour.