StaticName versus DisplayName on SharePoint Lists
Good old George2 asked a question over at SharePointOverflow.com about SharePoint list and column names today. If you don’t know it, SharePointOverflow.com is an excellent site to get high-end SharePoint assistance! I liked my response, so here it is as a blog post.
When you create a column on a list, both its DisplayName and StaticName are set to the same value. However, the StaticName contains converted values for some characters, most notably a space ‘ ‘ is converted to ‘x0020’. So if the DisplayName is ‘Product Description’, then the StaticName will be ‘Product_x0020_Description’.
There’s another little bugaboo: The StaticName is limited to 32 characters including the translations for special characters. Because of this, if you have more than one column with the same first 20 characters, SharePoint creates StaticNames as follows:
- ‘Product Description 1’ —> Product_x0020_Description_x0020_
- ‘Product Description 2’ —> Product_x0020_Description_x0020_0
- ‘Product Description 3’ —> Product_x0020_Description_x0020_1
- etc.
Clearly this renumbering can get confusing, too, so a lot of folks will create their columns without spaces in the names (ProductDescription1) and then change the DisplayName.
The easiest trick to see what the StaticName is (to me), to go to List Settings, and then click on the column name in which you are interested. On the Change Column page, the URL will end in something like:
/_layouts/FldEdit.aspx?List=%7B37920121%2D19B2%2D4C77%2D92FF%2D8B3E07853114%7D&Field=Product%5Fx0020%5FDescription
The StaticName is the value for the Field parameter in the QueryString. However, there’s more encoding to deal with: the underscores (‘_’) are converted to ‘%5f’. So Product%5Fx0020%5FDescription means Product_x0020_Description again.
Whenever you change the DisplayName, the StaticName stays, well, static. This often results in DisplayNames and StaticNames that have nothing to do with each other, so as you are prototyping, it’s a good practice to delete columns and re-add them if you are changing their purpose and therefore their name.
Good post. This has long been useful and practical knowledge, and you do a great job at explaining the extra details in a concise manner.
So, what should we think of Microsoft’s SharePoint 2010 Client Object Model for ECMAscript (aka javascript)? Microsoft only allows the referencing of field names using the static name. Bummer. While this makes sense because the display name can be changed and your script will break, it is still a pain to force the developer to discover the internal name. It also prevents quick “proof of concept” scripting from a console like Firebug, which I recommend be part of any javascript development routine. Try a code snippet in Firebug, then paste into your javascript file.
It is a design decision. Marc, how did you decide to handle this problem with field names in your SPServices lib?
For the jPoint lib, we decided to give the developer easier options in addition to the static name. jPoint allows the developer to reference a field using either the static name or display name. So, for a column/field to be called “Product Description 1”, jPoint allows you to reference it using jP.Form[“Production Description 1”], jP.Form[“ProductionDescription1”], and jP.Form.ProductionDescription1. Easy enough right? Well, what happens if there is another column/field called “ProductionDescription1”? You have a collision. I had thought about this before, and that’s exactly what Mike Ammerlaan, Microsoft’s program manager on the SharePoint team, asked me during a javascript discussion. It smells like jPoint needs a special function to detect the collision and append an integer at the end.
My point is, what is the best design? Shouldn’t we give the developer more options and easier options? Obviously, the answer is yes. But what if the easy options come with caveats?
-Will
Will:
As always, good comments and questions from you! You’re further along thinking about SharePoint 2010 than I am, I must say. Even so, the details you posted above come as no surprise to me when I think about it. The StaticName vs. DisplayName decisions that were made by whomever years back cause some issues, whether you are an end user blissfully using SharePoint or a developer slogging through C# code.
Interestingly enough, I was having just this sort of debate with someone over in the discussions for the jQuery Library for SharePoint Web Services today. (No, I wasn’t just looking for an excuse to mention it!) If you read through this thread, you’ll see that ombacke asked me about this very thing.
About halfway down the thread, s/he asked: “Another small question for $().SPServices.SPCascadeDropdowns is it possible the parentColumn and childColumn be the internal names of the fields and not the display names? I think it would be safer that way at least we know that once created the internal name wont be changed. Because users can easily change the display name of a field.” and my subsequent bottom line answer was “As far as the StaticName versus DisplayName question, I made a conscious decision to go with the DisplayName. I wasn’t comfortable with using the comment contents as my selector. Given that there are a lot of folks out there using the library right now, it’s not the time to change the logic on that, though perhaps I could expand it to accept either value. That might introduce other issues, though.”
In this, I was just talking about how I “find” a column’s controls in the DOM, but it’s really the same issue you refer to. There are two names for any column. (Actually, when you are using the Web Services, there is a third: the “ows_”-prefixed name. Someone explain *that* decision to me! I know – Office Web Services. I’m sure it, too, made sense at some point.) As I said in the thread, I’ve consciously decided to use one or the other in specific places. Not an ideal answer, but it avoids the collision issue that you asked about and I alluded to.
I don’t know what the “right” answer to all this is. We’re dealing with historical decisions that can’t (and probably shouldn’t) be undone. I’ve thought of doing what you’ve decided to do in jPoint, allowing the developer to choose. I’ve also built a function called SPGetDisplayFromStatic which does what it’s called; there probably needs to be the converse available as well. Another thought would be to introduce some notation like “^DN^Production Description 1” or “^SN^Product_x0020_Description_x0020_”. (I’m intentionally using ugly notation to get the point across.)
Maybe we should agree on a convention and tell everyone we have the best answer? ;+)
M.
It’s worse than that. You should get in the habit of using intelligent static names because any person with design rights could change the display name. You don’t want to reference any fields by display name. This is why CAML and most API methods expect a static (internal) name because it won’t change. If you ever do prototype you can create the column with the intended static name and then update it with the display name. But always write your code to reference the static name. Since you are limited by 32 chars for internal name – pick something short and sensible. Use the display name to expound and describe the field. Or use the description attribute, even better.
Also a correction. When sharepoint “shortens” you field name to 32 chars, it truncates at 32. If you have multiple with identical 32 chars it doesn’t add _1 to make it unique it removes the last char and replaces with 1– so it doesn’t add an underscore. That would increase the length to 33. It really does stop at 32. I had to write a translator method to figure out the 32 chars for poorly named static fields. Using this rule I never got it wrong.
Brian:
The “It’s worse than that” part of your comment is indeed even truer than you probably meant. Because of your correction, I just rechecked my ‘Product Description’ columns to be sure I had it right. The first column you name ‘Product Description n’ gets no postfix. The next gets 0, the next 1, etc. Here’s what I mean. I added the columns in the order below to a list and here’s what I ended up with:
As you can see, the sequencing number at the end of the StaticName is added in the order in which the columns are created. (Note that the first three columns I added ended in 3, 2, and 1, in that order.) So not only is the 32 character limit “soft”, it can go to 34, and I’m extrapolating 35 or more, but i’m not going to sit here and add another 90 columns to prove it!
M.
I learned early on that the best thing to do (and I teach power end users) is to always *INITIALLY* key in the column name with no spaces (e.g., ProductDescription) and then *IMMEDIATELY* change the name to the one you prefer (e.g., Product Description), which changes DisplayName but leaves StaticName unchanged. I had a large customer come up with his own Custom List he wanted my workflow to work with and, because I had “taught him well”, was able to use SharePoint Manager to pull a copy of the XML for his “hand crafted” example Custom List and use it for creating all the usual XML “goo” (fields.xml, schema.xml, etc.) that became part of the custom workflow’s feature and solution (wsp). I’m on a new project where I’m modifying an XML document in a Document Library and having to deal with the previous developers’ dedicion to not follow the above device which means I have to constantly translate _x0200_ to/from spaces during various processing steps.
I think it might be important to note that internal name and static name are not the same thing. The former is cast in stone when it is created in a list, but the latter can be changed — especially by feature redeployment.
I have a bit of detail in a blog post I did here: http://www.sharepointlessonslearned.com/blogs/blog1.php/2010/02/16/the-three-names-of-a-site-column
Thanks very much for this. I was extremely puzzled why I couldn’t my process to insert new jobs into the calendar. The static names with no spaces trick worked perfectly. Thank you! Thank you! Thank you!
in my case I have another problem, some of the columns of a list are seen with the static name to a client but my team and I see the names correctly, what could be the reason for this? From already thank you very much
@Jesica:
That sounds strange. Can you explain where they see the StaticNames? What version of SharePoint?
M.
It is in Sharepoint Online, I have a list with 4 columns of which 2 are shown with the static name
I can’t think of a reason people would see different column titles in the same view. The only thing I can recommend is to check the column names in the list settings to make sure they are what you think.