Every controller method having the setting of a property in VIewData is
horrible - cross cutting concern - so the attribute removes it from the
logic of the controller method ...
2008/8/27 Torkel Ödegaard <
torkel.odegaard@...>
> I have tried some different options for doing this (one of which is
> the solution you arrived at).
>
> The one I tried last was to have typed view data, where there was a
> base class for the view model that contained an enum for the active
> tab.
>
> so in the controller you would write something like
> var data = new HistoryViewModel()
> {
> Changes = repository.GetChanges(),
> ActiveTab = TabName.History
> }
> return View(data);
>
> That is then easily tested from a controller test, the probem with
> having action filters setting view data is that it makes testing it a
> little more difficult.
>
> And why is there a difference between remembering to add a
> NavigationalHint attribute and remembering to set a property in the
> ViewData collection?
>
>
> On Wed, Aug 27, 2008 at 1:13 PM, Casey Charlton <
casey@...<casey%40goinsane.co.uk>>
> wrote:
> > Just playing around with a new navigation we have ... and the simplest
> way I
> > can think of at the moment to "select" the current page on the menus is
> > something like :
> >
> > [NavigationHint("INDUSTRY ANALYSIS", "Headlines")]
> > public ActionResult Index()
> > {
> > return View();
> > }
> >
> > Where the attribute then puts these values into the ViewData collection
> for
> > the navigation controls to pickup ... this does mean that individual
> > methods/controllers don't have to worry about looking this data up or
> > remembering to set it
> >
> > Obviously this means the navigation is set in code rather than in
> > configuration ... the slightly messier option to allow some external (to
> > code) configuration is to put in some kind of lookup in config somewhere
> ...
> >
> >
> > Any other (better) ideas for cross cutting data like this?
> >
> >
> >
>
>
>