We Keep Coding

Is having variables for action URLs in a razor views a good practice? Can I put them in the ViewModel?

I'm trying to have cleaner views for readability and the ease of modification.
I usually have for each view a couple of variables that represents the action URLs used in it:
#model IndexViewModel
#{
// controllers
string newsControllerName = nameof(NewsController).ToName();
// calls to actions
string removeNewsActionUrl = Url.Action(nameof(NewsController.RemoveNews));
string getNewsActionUrl = Url.Action(nameof(NewsController.GetNews));
string indexActionUrl = Url.Action(nameof(NewsController.Index));
}
So I can use them inside the view's data attributes for ajax calls in JavaScript:
<div id="newsContainer"
data-remove-url="#removeNewsActionUrl"
data-view-url="#getNewsActionUrl">
...
</div>
Then a friend of mine suggested that I shouldn't declare variables in a view because it's a bad practice and why not declare them in the ViewModel of that view in this case the IndexViewModel.
I know that views shouldn't have complex logic and should have the minimum of C# code, but is what I'm doing a bad practice? If so why? and is there a disadvantage or an advantage to have variables declared in the ViewModel of that view for this purpose?
From Microsoft docs views and view model:
Views are responsible for presenting content through the user interface. They use the Razor view engine to embed .NET code in HTML markup. There should be minimal logic within views, and any logic in them should relate to presenting content. If you find the need to perform a great deal of logic in view files in order to display data from a complex model, consider using a View Component, ViewModel, or view template to simplify the view.
I couldn't find anything related to this on this site.

I wouldn't want this stuff in the view model. It's superfluous there as there is nothing to be communicated between model and controller.
I don't see an issue with this - it's minimal logic and it is purely concerned with the view itself. Putting it anywhere else would be polluting another part of the codebase for no good reason.
That said, I don't really see any good reason for the code block - why not just inline it in the HTML attributes?

Building HTML Twitter Bootstrap 3 in code

.NET 4.51 Webforms
I an writing some user controls and need to generate some HTML for Twitter Bootstrap 3. I was wondering if anyone had come across a class that would assist with this before I roll my own?
There seems to be an abundance of HTML helpers for MVC https://www.twitterbootstrapmvc.com/ but nothing where I can generate HTML from code behind easily. Yes I can use something like HTML helpers in Webform? or http://msdn.microsoft.com/en-us/library/system.web.mvc.htmlhelper_methods(v=vs.118).aspx or http://msdn.microsoft.com/en-us/library/system.web.mvc.tagbuilder(v=vs.111).aspx but if there is something out there already then I would rather use that than rolling my own.
Has anyone come across anything like this?

If your're talking about textboxes, textareas and so on, the best way to do it is by making a function that adds your custom html attributes to that element.
After that you should do method which returns MvcHtmlString
public static MvcHtmlString CustomTextBox(this HtmlHelper helper.....)
{
var attributes= customFunctionsToSetAttributes // Dictionary<string,object>
helper.TextBox(name, value, format, attributes); // mvc original .TextBox helper
}

What does an #functions code block in a razor file do, and when (if ever) should I use it?

Whilst looking at a theme I downloaded from the Orchard CMS gallery, I noticed that a Layout.cshtml file had this block of code at the top of the file:
#functions {
// To support the layout classifaction below. Implementing as a razor function because we can, could otherwise be a Func<string[], string, string> in the code block following.
string CalcuClassify(string[] zoneNames, string classNamePrefix)
{
var zoneCounter = 0;
var zoneNumsFilled = string.Join("", zoneNames.Select(zoneName => { ++zoneCounter; return Model[zoneName] != null ? zoneCounter.ToString() : ""; }).ToArray());
return HasText(zoneNumsFilled) ? classNamePrefix + zoneNumsFilled : "";
}
}
I know what the declared function does (calculates which zones are populated in order to return the width of each column), my question is- what is the correct use of the #function block, and when should I ever use it?

The #functions block lets you define utility functions directly in the view, rather than adding them as extensions to the #Html helper or letting the controller know about display properties. You'd want to use it when you can meet these conditions:
The functionality is tied closely to the view and is not generally useful elsewhere (such as "How wide do I make my columns").
The functionality is more than a simple if statement, and/or is used in multiple places in your view.
Everything that the function needs to determine it's logic already exists in the Model for the view.
If you fail the first one, add it as a #Html helper.
If you fail the second one, just inline it.
If you fail the third one, you should do the calculation in your controller and pass the result as part of the model.

Others have explained what #functions does so I won't rehash that. But I would like to add this:
If your view is typed to a viewmodel, I think a viable option would be to move this logic into the viewmodel to avoid cluttering your markup with too much code. Otherwise your views start to look more and more like classic ASP and I don't think anybody wants that.
I don't think there's anything wrong with using #functions or #helper in your view, but once you get beyond a couple of methods in your view, or even if the function is somewhat complicated, it might be worth refactoring to the viewmodel if at all possible. If it's code that can be reused, it may be a good idea to to pull it out into a helper class or an extension to the HtmlHelper class. One thing that is a bummer is realizing you just rewrote a piece of code that already existed because you didn't know it was hidden away in some arbitrary view.

From msdn blogs, #functions block is to let you wrap up reusable code, like the methods and properties

In this particular case, the people who have created the theme you are using probably were trying to keep it as a simple theme (only views, css and images).
If you need to write some code for a theme for Orchard, you have to turn to a module (as stated here: http://docs.orchardproject.net/Documentation/Anatomy-of-a-theme) unless you write this code in the view.
I am not sure it is worth the time to switch from a theme to a module only to get the size of a column.

Are IF..ELSE statements in a View frowned upon in ASP.NET MVC?

I know that you want to keep logic out of your views. I can elimate most loops by using DisplayFor/EditorFor and passing IEnumerables to the view.
What about IF statements? should they be avoided completely in views? used sparingly? as a last resort?
Say you wanted to show hide an element based on a User role...How would u go about doing this without an IF statement...a completely seperate view perhaps?
Just trying to get an idea of best practices.
Thanks!

Be consistent, and keep in mind the purpose of the view - to produce your HTML. Toward that end, certainly you will need some if constructs here or there. I think some people are suggesting you stick to some pie-in-the-sky, ultra-nitpicky purism here at the expense of usable, functional, well-defined code.

There is nothing wrong with using ifs in your views, as long as you don't end up putting backend logic in them.

Rob Conery has a rule of thumb that states "if there's and IF, make a helper". Personally, I would say "use sparingly". I avoid it as much as possible because it makes things more difficult to unit test.
For the situation where you want to hide elements based on user roles: For simple scenarios, I would probably put the check directly in the view. Usually I try to still make these more terse and testable, though. So instead of:
#if (HttpContext.Current.User.IsInRole("admin")
{
// Show admin stuff
}
I would do something like:
#if (Model.UserIsAdmin)
{
// Show admin stuff
}
On the other hand, if these kinds of checks started getting speckled all over your views, I'd probably create the elements conditionally in the viewmodel first, and then just display what's been built. Hope that helps.

Basically every View should display whats passed in ViewModel. If ViewModel is not enough, then I would look for a way of improving the ViewModel creation itself, not the View's logic.
All conditionals CAN be evaluated upon ViewModel creation.
Of course, It all depends on how much custom-logic in View does Your project organization tolerates.

I think is the better to avoid if in the view, You should avoid business(Model) or application(Controller) logic in the view
in your example you can create different Partial View for display some think depend on user role and in the Controller put the logic for what view you need to show

If / else can be used sparingly, in my opinion, but for the example you mention, hide an element based on role - the if check should definitely not be in the view. Write extensions and helpers where needed.

I would suggest to hide element by "if" in the view, but in code you must disable function (method), which is activated by hidden element.

Moving complex conditional statements to code behind

I was just wondering, if by moving complex if else statements and the resulting html markup to the code behind violates some 'MVC' law?
It seems like a great option when faced with inline if else statements that can become extremely unreadable.

It's not horrible to have conditionals in your view. I would keep them in the ASPX not the code behind. However, a conditional often indicates controlling behavior. Consider the following ASPX code:
<%if (ViewData["something"] == "foo") {%>
<%=Html.ActionLink("Save", "Save") %>
<%}%>
<%if (ViewData["somethingElse"] == "bar") {%>
<%=Html.ActionLink("Delete", "Delete") %>
<%}%>
This set of conditionals represents controlling behavior that is being handled by the view -- i.e., in the wrong place. This behavior is not unit testable. Consider instead:
<%foreach (var command in (IList<ICommand>)ViewData["commands"]) {%>
<%=Html.ActionLink(command) %>
<%}%>
In this example ActionLink is a custom extension of HtmlHelper that takes our own ICommand specification object. The controller action that renders this view populates ViewData["commands"] based on various conditions. In other words, the controller does the controlling. In the unit tests for this action, we can test that the correct set of commands will be presented under various conditions.
At first this might seem like a hassle compared with quickly throwing a few IFs into the view. The question you have to ask yourself is, "Does this IF represent controlling behavior, and do I want to ensure does not at some point break?"

I prefer not to use the code behind class in my views. This is not because it violates MVC by default, but because I found that the "natural" way (at least for me) is different.
When I face complex HTML markup that relates to purely view concerns, I usually write an extension method for HtmlHelper class in order to hide the complexity. Thus I have extensions like Html.MoneyTextBox(), Html.OptionGroup() and Html.Pager<T>.
In other cases when complex conditions arise, usually I missed something from the controller. For example, all issues related to the visibility, readonly or enabled of elements usually stem from something that the controller can provide. In that case instead of passing the model to the view, I create a view model which encapsulates the model and the additional info that the controller can provide in order to simplify the HTML markup. A typical example of view model is the following:
public class CustomerInfo
{
public Customer Customer { get; set; }
public bool IsEditable { get; set; } // e.g. based on current user/role
public bool NeedFullAddress { get; set; } // e.g. based on requested action
public bool IsEligibleForSomething { get; set; } // e.g. based on business rule
}
That said, the code behind is part of the view, so you can use it freely, if it fits your needs better.

I believe as long as it's a rendering code and it's in a "View" not in a controller, then putting it on code behind or inline won't matter. Just make sure that you don't write this piece of the rendering code in the Controllers actions (this way you will really violate the MVC pattern).

The codebehind is part of the View -- it's up to you if you want to put things in the ASPX directly or in the codebehind. MVC doesn't mean you have to code things all ugly in the ASPX :).