Is menu link suppression the responsibility of the viewer or the controller?
In ASP.NET MVC I am building a site with a requirement that the main menu (appearing on every page) will remove the hyperlink for the post (leaving only the text) if the current page is linked to it.
The html menu is defined on the main page of the site, but is currently populated from the ViewData passed by the controller. This is configured so that the base controller defines a dictionary of reference objects, then actions on the controllers grab the corresponding entry from the dictionary, set the address to empty. The underlying controller then passes it to the view as IEnumerable<>
.
However, looking at it with a critical eye, it looks more like something that only a point of view should respond to: the menu does not change, so the dispatcher feels like he is afraid to go where he should not. My only small caveat is that the View will be aware of what the current page is, which looks more like a controller issue.
I've been arguing around in circles in my head for a while, so I'd like to get some other opinions on this. I would have thought this would be a fairly common scenario?
(One final clarification to my problem: the main menu links are the "landing pages" of the various areas of the site (basically the index action of all controllers), and once you've navigated to the area and from the landing page, all menu entries will be linked)
source to share
We might think that views look very silly, since their only job is to turn the data provided by the controller into something that the client can parse and display.
However, in reality, most of the views (of course, all the ASP.NET-MVC examples I've seen), significant application logic is embodied in views, since it is the view that dictates how the user can navigate the application. If it weren't for the view, including the code for creating clickable links, images, and buttons, we wouldn't have many applications.
Hence, a view containing a menu in which it controls the content does not contradict the spirit of separation of concerns. OTH, also an acceptable controller providing some of the list for inclusion in the menu. In this case, you would expect the controller to dictate which menu members should be clickable, the role of views in this scenario will be the controller's wishes.
source to share
I would like to create a controller to display a menu. I guess too much logic in the view makes it difficult to save.
Not showing manu man entries that it cannot use is for some reason part of your application logic and not the view itself. I always try to treat the view as a dumb piece of code that just does what it needs to do - loops, basic display related ifs, stuff like that.
Also, passing important enough data to the view can make the application easier to test.
source to share
I agree with AWJones that this is a bit of a gray area, but imho if the view is supposed to be responsible for how something is presented and the controller is responsible for something, then the menu content is in the controller domain.
I feel like "suppressing" parts of the menu should be completely hidden from the view (and the end user) - the view should get what it wants and no more.
source to share