1

I've got a view that renders a menu. These menu items are dynamic, in that they only appear based on some conditions (authorization, for example).

I have two options:

  1. Hard code the menu in the view with all the necessary conditionals
  2. Structure and filter data outside of the view so the view is only responsible for displaying an array of actions.

Option 2 seems to be more elegant to me, but this seems to come at the cost of increasing the size of the controller and doesn't feel like it should be the responsibility of the controller.

So, my questions are:

  1. Is structuring data for the view standard practice?
  2. Where should the structuring of this data live? I've considered using a helper method (imported from module), a service object, or just a private method within the controller, it's just not clear to me which would be better.

Beyond just answering the above questions, I would appreciate any insights in how to approach these types of conceptual issues.

For what it's worth, the MVC framework I'm using is rails.

3

I prefer putting as little logic in my views as possible. Yes this bulks up the size of the controller, but you can counteract this by splitting it up in multiple methods, functions or classes, as you mentioned. I personally wouldn't put this code in a service object. It's the controller's task to take data from the model and transform it so that it's easiest for the view to render.

  • Seems like job for concerns – Fabio Feb 17 '18 at 6:20
  • Do you believe it's the job of the controller to actually transform the data, or to orchestrate the transformation by calling a class that does this? – cgat Feb 17 '18 at 16:39
1

I have two options:

  • Hard code the menu in the view with all the necessary conditionals
  • Structure and filter data outside of the view so the view is only responsible for displaying an array of actions.

The folks that write the views are also the folks that do the layout. When your team grows, you tend to see more visually-specialized developers in that role. You don't want them writing business logic, honestly. They are much more valuable writing jquery, css, etc. Their focus should be making the page beautiful. Back-end developers should hand them a clean, useful, pre-filtered and pre-sorted list, computed in the controller (or service layer if you have one) and stored in the model. The person writing the view should only need to worry about putting the tags in the right place, or at most writing a simple foreach loop.

Is structuring data for the view standard practice?

Yes, that is the purpose of the model.

Where should the structuring of this data live?

The model

I've considered using a helper method (imported from module), a service object, or just a private method within the controller, it's just not clear to me which would be better.

Use the model

Beyond just answering the above questions, I would appreciate any insights in how to approach these types of conceptual issues.

Read the abbreviation

  • Hmm, okay. I think part of my problem here is that I'm attached to the idea of a model being a representation of a table in the database (or a row in that table). In this case, set of actions are specific to the view, so are you suggesting I create a class that is composed of the dependent objects and embed the conditional logic in that class? The difference between this (and calling it a model) and a service object seems arbitrary (perhaps it's just a conceptual thing) – cgat Feb 17 '18 at 16:38
  • I think people mix those up all the time. The model in MVC is a behaviorless container for all the data that the view needs. The controller populates it by reading from the business layer or data layer, which may have its own version of a model. Also, several models from the business layer may be needed, but there is only one model for the view. Yes, you may end up writing code that maps between the two; that is a normal part of separation of concerns. – John Wu Feb 17 '18 at 20:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.