Adding Styles to Built in Editor Templates in Razor

I thought I’d blog about this thing I keep forgetting the syntax for and I’m sick of Googling for it. It’s a bit of a niche thing in Razor. First, some background.

Previous to MVC 5, you could not add any styling to any of the built-in EditorTemplates. So, if you wanted to add a Bootstrap style to an input, you had to fall back on the simple Editor extension method:


@Html.EditorFor(m => m.Name, new { @class = "input-lg"}) // won't work
@Html.Editor ("Name", new { @class = "input-lg"}) // used to be OK - before MVC 5

The EditorTemplate would simply ignore the style. And if it happened to be the first time you bumped up against that foible, you probably blew half a day figuring out that it was not supported.

Someone whispered in Microsoft’s ear, because they changed this in MVC 5 (possibly the 5.1 release). The following syntax enables you to have your cake and eat it:


@Html.EditorFor(m => m.Name, new { HtmlAttributes = new { @class = "input-lg" }})

Note, you now have to use that new syntax with the simple Editor extension method as well.

Related Entities Already Attached to the Context Being Automatically Referenced

I stumbled across something today which had me quite stumped for a while and is worth blogging about. I feel like this is something I should have known, and probably did know, when I first read books and articles on the Entity Framework. But alas, if I did know, I had forgotten.

I was working with a repository which had a DbContext for data access, with both lazy loading and proxy enablement set to false. So, no proxies and no lazy loading.

I was iterating a list which did not include any “include” statements. So no related entities of the entities in the current list should have been eager loaded. However, I was noticing that there were related entities loaded for the entities in the list. Not all, but one particular related entity.

I had to get to the bottom of this, so I created a solution which used the raw DbContext, to rule out anything happening in the repository’s code that was loading the entities. (Note, I did read through the repository code and could not see any culprit.)

If you look at Figure 1 below, a list of Person entities is displayed and I have maximised one as an example (that of Terry Halpin). You can see that the Lendings related entity is null. This is exactly what I would expect from a DbContext, where there is no eager loading involved (no “includes”). So, for a while there I was convinced that something in the Repository was eager loading related entities, when not actually called upon to do so. And that would be bad.

Figure 1 - No Value for Lendings Related Entity

Figure 1 – No Value for Lendings Related Entity

This bounced around in my head for a while and I was not convinced. Then, I had a “penny drop” moment when debugging the offending code ->>> perhaps the Lendings were being retrieved and brought into memory (Local) at an earlier point in the program’s flow. I knew, for sure, that other things were being retrieved previously. So, if they are already in memory, were they automatically being referenced by the new objects, that were being loaded into memory, without any “include” statements?

So I went back to my small experimental solution to test my theory. That theory being:

If an entity is a related entity (the “Related Entity”) of another entity (the “Primary Entity”), and that Related Entity is already in memory by the time the Primary Entity is itself loaded, then the Related Entity will accordingly be a non-null member of the Primary Entity.

Now THAT was a mouthful, so I will elaborate with a screenshot. But before we look at it, quickly look back to Figure 1, where all that was being retrieved was a Queryable of Person entities.

Now look at Figure 2:

Figure 2 - Lendings Related Entity is now populated

Figure 2 – Lendings Related Entity is now populated

There are 2 things to note:

  1. Before retrieving the Person entities, I have retrieved a list of Lending entities and forced the loading of that list, from the database, by calling ToList().
  2. Now, if you look at the same entity which I expanded in the Person list (Terry Halpin), you will see that the Lendings related entity is populated (not null). But I have not used the includes extension-method to eager load those Lendings.

Now I’m going to go walk my dog.

Shortcut to Collapse All Projects in Solution Explorer of Visual Studio

It’s nice to be able to collapse all projects in Visual Studio Solution Explorer. If you hate mice like me, it’s even nicer to have a keyboard shortcut to do that for you.

In Visual Studio, go to Tools > Options > Keyboard. In the Show commands containing text box, type in CollapseProjects. Select the ProjectandSolutionContextMenus.Projects.CollapseProjects and assign it your shortcut as shown below:collapse projects shortcut

Server Name Indication – Bind Different Certificates to 1 IP Address Using the Same Port

In the old days, you could only bind a single SSL certificate to an IP address in IIS. So, if I was using host-headers to have more than 1 site at the same IP address, I could only bind a single SSL certificate to port 443 of one of those WebSites. This was a bummer. In my day job, owing to some limitations, we have our Testing Site on the same server as our Staging Site. As a result, I’d have to bind the Test Site’s certificate to a different port. And as the web server can only have 1 default port for SSL, the 2 urls would be:

  • https://somesite.staging.organisation.org/
  • https://somesite.testing.organisation.org:444/

Nowadays, you can have your cake and eat it. And all it takes is a single checkbox:
Server Name Indication

It’s called Server Name Indication and if the CheckBox is checked for the sites using the same port (presumably 443), then you can bind different certificates to different sites (with distinct host-headers) on the same IP address and the same port.

Currying to Rein in Underscorejs

Whilst I am a big fan of Underscorejs, today I am going to show you a small technique to rein it in. So, first I will show you the problem which I am going to solve.

When you use the Underscorejs methods for manipulating/iterating collections, Underscorejs usually passes in three parameters to the function which you use for the call-back:

  1. the current item being iterated;
  2. the index for that item in the collection; and
  3. the whole collection itself.

The easiest way to verify that, is to put a breakpoint in your function, open the console in either Firebug or Chrome developer tools and type the word arguments (see the following screenshot):

threeParams

For one reason or another, you may want to confine the arguments which get passed in to the first one. You may be only interested in the item being iterated. And to lock your method down, you may want to effectively block the other 2 parameters from being passed in (note how I keep using the word “may”. Most of the time, you’ll be quite happy to have access to all 3 parameters).

To do that, I am going to write a small helper function which I will call curryOneArgument. That function will use the technique of currying to return a function that will only receive one argument:

var curryOneArg = function(fun) {
        return function(arg) {
            return fun(arg);
        };
    };

Now, all we have to do is wrap our call-back in that new function and we will be restricting that callback to only receive one argument from Underscorejs:

var newColl = _.map(coll, curryOneArg(function (arg) {
            
            return arg.name;
        }));

And, using the console to verify:

oneArg

Verified!