tags:

views:

211

answers:

3

One of the goals of the MVC approach to web development is to separate out the model, view, controller.

Lets say in a J2EE Struts like environment, you associate the Struts Action with the controller, a Java bean with the model, and JSP and/or ActionForm with the View.

My question, where do you tend to perform any logic to populate data on the JSP. It seems bad practice to put any kind of logic or processing in the view ActionForm and very bad to put any kind of logic in the JSP.

Do you include a "Manager" class to manipulate the data in the View Form before it is display ed to the user.

Here is one simple example. You take First Name, Last Name out of the database and then you need to pretty the format (convert all upper case string to Mixed case). Would the logic to manipulate that string before it gets to the JSP view, add that logic in a manager class?

+3  A: 

If it's logic that is only concerned with the view (in your example, making the data look "pretty"), then I would put it in the View. If, however, you would be later saving the modified data, then it should be in the business layer. In general, though, I tend to keep a layer between the View and the Control (your Manager class) that is only concerned with display issues and high level validation of input, but not complex business rules (ensure that very bad data never reaches the business tier).

Elie
+1  A: 

This very much depends on what framework you're using. I think this kind of thing should be done in the view, but exactly how you would go about that will vary.

If you're using a JSP it might make sense to write a custom tag library to do what you want - so it's separate from the actual HTML but still within the 'view'.

So, you would have something like:

<td><mytag:mixedCase value="${user.firstname}" /></td>

Etc.

Phill Sacre
A: 

For simple presentation concerns such as uppercasing a string, I would put it in the JSP. For more complex business logic, I would put it in the model class. You don't want to be cluttering your controllers with business logic. Another advantage of putting it in the model is that it can be unit tested.

John Topley