Duplicate object values in ASP.NET MVC DisplayTemplates? Easy fix.

Duplicate String values

Are you getting duplicate object values (or whatever those Objects output in ToString())? Eh, so was I. Found a fix, though.

Description

Okay – I just ran into one of my more stupid mistakes since.. Well, since forever.

I had made some quick and simple edits in String.cshtml displaytemplate (among quite a few other edits before building again and seeing what happened), as I added support for Enum values there. After that I started getting duplicate values for String-typed properties. 

Apparently, mistakes were made.

Solution

Luckily, this was easy to fix (but still worth documenting): I had added the code for handling Enum-values, and also changed “@model String” -declaration to awful “@Model object” -one. Changing the type was supposed to happen, but capitalizing the model messed up my DisplayTemplate. Instead of casting the model to object, I was simply calling Model at the start of the template (basically, that was a shorthand for Model.ToString()), hence the “String object String”-kind of duplicate values on DisplayTemplate.

Continue reading

How to properly use SPWeb.AllowUnsafeUpdates?

SharePoint2013

At times you may need to allow unsafe updates to SPWeb objects to get your code to run. This, in SharePoint C# code-behind is done by setting SPWeb.AllowUnsafeUpdates to true. However, as this is an exception to security settings, and should generally not be done, it’s a good practice to limit the change to as small a scope as possible – even though the setting is only persisted for the duration of the request (unless the SPWeb object was gotten from SPSite.GetWeb() or SPSite.Webs[]).

What to do?

I’ve found the easiest way to temporarily allow unsafe updates in a safe way but without too much of extra code to be this:

Please note, that it’s unwise to simply set the AllowUnsafeUpdates to false after the code, because there’s an ever-so-slight possibility of it screwing up some other code running in the same context at the same time! And of course, it’s likely to be unwise to allow unsafe updates if you’re handling data that was gotten as user input.

Programmatically creating SPFields with readable internal names

SharePoint Field Name Problems

This post is about a small programmatic workaround to creating new SPFields for SPLists in SharePoint with human-readable internal names. This is mainly an usability improvement for your editors, but they’ll probably appreciate it!

Problem: non-readable internal names for SharePoint list fields

When you create a new field on SharePoint, SharePoint accepts the following syntax:

However, this will result in the internal name to be something like “Field_x0020_name_x0020__x002d__x” which is hardly readable, but rather quite horrible to look at, or use anywhere at all.

Luckily, there’s a nice and straightforward way to solve this issue and produce nice and readable internal names for SharePoint list fields!

Solution

If you need to get readable internal names (like when your editors actually use the internal names for something) for your fields, you can use a code similar to this:

Continue reading