MVC - Who formats the model?

Question

Before rendering to a view model, you should format:

• localized local data;
• dates, time values ​​are formatted;
• numbers are formatted.

Who does all this formatting - Controller or View?

Am I right that all formatting is done by a controller that creates a so-called ViewModel containing only formatted values ​​and sends this ViewModel to the View?

Thanks in advance!

Answer 1

Eric Petroelje is right, but I would build a helper class (s) to get localized content / dates, etc., because localization is not always in views, for example. sending emails with localized content. I would have something like LocalisationHelper.GetString ("MyKey") or LocalisationHelper.GetDate (Date.Now), where LocalisationHelper knows the current language of the user (possibly from the session).

Then use this directly in the views where possible:

<%= Html.Encode(LocalisationHelper.GetDate(Date.Now)) %> 

Answer 2

Design Patterns 101.

The model is designed to store data (usually with database support).

A view is intended to represent data (without manipulating it).

The controller is designed to manipulate the model and transmit this view (choosing the right locale, for example, will go here).

MVC does not necessarily mean that you have 3 different classes, but 3 components or layers. They are abstract and do not have to be tied to one physical class. Inside your controller level, which may consist of any number of helper classes or any other.

I agree with part of what the cartoon says, everything is intertwined. For example, if you create a view for a shopping cart, but the model contains birthday information, then it will not work. This is just a design template that helps eliminate duplication of effort. When you have less variables and less noise, it’s much easier to focus on what needs to be done and understand it very well.

I had a discussion with our team about using annotations to render forms on a web page. These annotations were placed in a model or entity class. You will often work directly with entity classes, so it eliminates quite a lot of overhead and duplication of effort if you post your annotations here. Since your annotations are placed directly on the model class, you cannot get a glimpse of the birthday, it is simply not possible. In addition, following the patterns, you remove garbage that does not add value to the final result. You just write business logic and don't come close to anything else.

Although annotations were in the same class as the model level, the presentation or presentation level consisted of annotations and auxiliary classes. It does not have to be different classes or borders.

Another example. In the past, I have worked on some “applications” on the Internet. I use applications because they were a monolithic block of code, more or less the only main method with all the logic there (which is hardly a functional application).

If you do not abstract code in functions and just use one method, you will get a lot of duplication of effort. If you tried to understand this monolithic code block, you would run into a bunch of troubles (like me, it was hard to find out what was going on, then I would find a similar code block somewhere else and be stunned why few things were changed the way they were).

You can do it the way you want, but design templates such as MVC will help you simplify what you write to make it work, and easily wrap your head around the solution. Another popular design template or approach is shared and won.

To answer your original questions:

In Java, localized data will be executed transparently by the application. For example, if you want English support for English, you must create a properties file:

messages_en-US.properties

and then post all your American English content there. Depending on how much content it can be, you can use a different approach.

For my application, I have whole pages in another language, so I do this. My controller determines the client locale or best match. Then he selects which view displays and passes the model (data) to the view.

If you need dynamic formatting for your date / time, your controller is responsible for determining which one will be used. Then your view is responsible for using this converter to format the value.

I use JBoss Seam, so the MVC design pattern is still used, but more abstract. I do not have the actual “controllers”, but an interceptor that is responsible for processing certain functionality (determining the client’s locale, and then another for their preference for date / time). My controllers, which would be equivalent to the Spring controller, are the action components responsible for handling the actions on the page.

Walter

Answer 3

All this is similar to presentation level logic, so personally I think it should go in the view.

ETA:

I would not advocate that call level service level objects in the general sense, but for localization, I think it makes sense.

For example, let's say you have a lot of static text on your pages that you have designated and stored in the database in various localized forms. I don’t think that the controller will need to search and put all these text tokens into the model. Despite the fact that the text token is technically a "service level", I still think that it makes sense for the view to call this service directly through some utility class, rather than using a controller.

Answer 4

The view is responsible for this , not the controller.

To explain, I need to talk a bit about what a "view" is:

In MVC templates based on the web interface and the traditional graphical interface, View is responsible for the external representation of any parts of the displayed model . If this means "formatting" the data from the model, then it is.

The controller does not have to format the data - because the controller is responsible for doing things with the model based on events / commands coming from the outside world. The controller has nothing to do with rendering output.

Example:

I want to display a shopping cart with several order lines:

• Adding things to the basket causes the controller to change what is in the basket model.
• Changing my locale causes the controller to change the setting in the user model to indicate the preferred language.
• Whenever a basket is displayed, the view should ask the model for the order lines and decide how to display it, possibly doing a locale-specific job.
• The same customer may ask for a shopping cart in different currencies. It just means changing how it looks in the view. This is another one and the same basket for the same customer with the same things in it.
• If this is a web application created on web template pages, you can embed code to pull localized messages, for example. <%= message_renderer.text(:insufficient_funds) %> . In this case, message_renderer and the template file are part of the view.

Views are not necessarily just web templates. In some Java environments, for example, we put “view objects” in the speed template. These view objects are tied to model objects, but also perform on-demand rendering and formatting operations. This is part of the presentation, although they are not just a template.

This confuses frameworks a bit, such as ruby ​​on rails and groovy on grails, where they invoke the "view" template - when the view is really more than just a template. Traditionally (in Smalltalk MVC and Java Swing), views are just code that can perform formatting, rendering, and any other display-related behavior.