You’re right to question what to do here because as soon as you open the ‘code smell’ Pandora’s box it’s difficult if not impossible to close.

Would it be possible to add boolean properties to your view model, such as CanAddUserVisible?

If so you could use an html helper in the view model to determine if the display value of the button/control should be block/inline or none it should be hidden.

This approach would be testable and could be done using a single view without any conditional logic.

I’ll try a write a blog post in the next couple of days with an example of the above.

In the meantime, if you come up with an alternative solution let me know.

Cheers,

Jag

1. Have a bunch of if’s in the view to control that gets rendered…. Back to the logic in the view, granted is “view” logic, but untestable, hard to maintain, etc.

2. Return different views depending on the combination of shown/hidden controls… this could get really messy really fast if you have many combination

3. Have a helper class emit the correct html… testable but we are back to the “who render that html”

Any other thoughts?

Thanks for your comment.

I have updated the post with you’re suggestion. I would not add a method onto the view model to do this but that’s down to personal choice.

Just be aware if your workplace requires developers and designers to work together you might not be able to use some of the templating features coming in ASP.NET MVC 2 such as UIHints.

Also if you’re compiling your ASP.NET MVC views make sure this is only done on your CI server not on your machine because it increases build time. Check out this DimeCast about Performing Static Page Checking in MVC.

What a designer should be doing is controlling the css and placing the data (from a view model) appropriately within the tags. All the options presented don’t allow this and force the designer down the route of contacting a developer for a re-compile if they want to alter a class.

Yes the business logic of 3 levels should be controlled in code not the view as you highlighted, but isn’t that where the view model comes in? In this case it’s something we want to do a lot so we can delegate the detail from the view model to a helper as you have done but I feel the key is not to hide anything the designer may want to change.

Why not have a method on the view model with the following signature string StockLevelCss(string noneCss, string lowCss, string highCss) This would make the decision about which (css) string to return based on the stock level known within the view model. Tests would be simple, straightforward and long lasting.

Within the view the designer now has control to alter the css as they wish, ok so there is the chance of typos within the view but that’s an acceptable price to pay as the toolset can easily help you there.

If the business logic changes to have 4 levels then the method can either gracefully degrade to return one of 3 levels. Or more preferable fail MVC view compilation, highlighting the issue for the designer to fix.

My vote is for option 4 keep css and tags out of code.

I suppose it depends what you see your controller responsibility as being, but for me it’s the gateway between http and your system. As such, templating concerns should stay within the template, and the controller should have no idea about it, and no involvement in it.