MVC Views: Show Logic?

Question

I read this article: Ensuring Strict Model Separation in Template Machines (PDF).

He claims that you need only four constructs in the views:

• attribute reference
• conditional inclusion of a template based on the presence / absence of an attribute
• recursive template links
• template application with a multi-valued attribute similar to lambda functions and LISP s map operator

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

It is reasonable? Most MVC frameworks allow any logic in views, which can lead to business logic creeping into the view. But can these four constructions be dispensed with?

For tables with a green bar, the document proposes to compare the list of templates in the data list - for example:

 map(myList, [oddRowTemplate, evenRowTemplate]) 

But what if you want to make the first and last lines different styles? What if the 3rd line should be purple on Tuesdays because your graphic designer is crazy? They are view-specific (for example, if I output the same data as XML, I would not use them), so they do not seem to belong to the model or the controller.

In short:

• Do you need logic above the four constructs listed above in the views?
  • If so, how do you limit the crawling business logic?
  • If not, how would you do the third row of purple on Tuesdays?

Answer 1

Terence Parr is a very smart guy, and his article deserves special approval, but from a practical point of view, I found that the use of these constructions somewhat limits.

It is difficult to prevent business logic from being run, especially if you have the ability to do something, such as ASP.NET and JSP. It comes down to how you spend your time:

• Allow limited advanced features (I'm not a proponent of “nothing”) and use code verification mechanisms to ensure proper use or
• Limit the four constructs above and spend more time providing attributes such as valueLessThanFive (remember to rename it to valueLessThanSix when changing business requirements or adding valueMoreThanThree - this is a bit appropriate as an example, but I think you'll know what i get).

In practice, I find that resolving conditional and circular constructs is useful, as it allows traversal of properties, such as attr[index].value in template expressions. This allows you to effectively manage presentation logic, while at the same time exposing yourself to a negligible risk of abuse.

Allowing more functions, such as calls to arbitrary methods, is becoming increasingly "dangerous" (in terms of facilitating misuse). To some extent, it comes down to a development culture in your environment, development processes, the level of skills and experience in your team.

Another factor is that in your environment you have the luxury to ensure a strict separation of work between presentation and logic in terms of the availability of specialized designers, not programmers, who would be delighted with the advanced designs in the template. In this case, you will probably be better off working with more limited template functions.

Answer 2

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

The original (or one of the earliest) MVC templates had a View view, which is a data view; the template did not have a user interface concept. Modern versions of the MVC template felt the need for this representation of the data, so we have things like MVVM, MVP, even MV-poo . Once you can create a "representation" of your user interface-specific data, it’s easier to solve a lot of problems.

In our case, our model will receive additional properties, such as style or color (the style is better because it still allows the view to determine how this style is presented). The controller will take the original “model” elements and display the elements of the custom “model” with this additional style, giving the third line on Tuesdays the “MadDesignerSpecial” style, which is used to apply the purple color.