Safer request form fields in list forms using JQuery

Mark Anderson published today an article on his blog concerning an issue that currently exists in Office 365 and is called “Office 365 Update Changes ‘Display Name’ on Required Fields”. In this article he described that the rendering of fields recently have been changed in Office 365. I will take a look what can be done to solve this probably.

The cause of the problem

The title attribute of list fields have been widely use to customise forms in SharePoint using JavaScript, JQuery or SPServices. I used this attribute sometimes too do address fields by the display name. But somehow I always had a bad feeling about this. Why? Well, the ID attribute of the field is the only real unique identifier in the form. The downside using the ID is that you need to have some information about the field to generate the ID. But I will explain this later.
What the update recently in Office 365 did was to change the rendering of the field. Previously it look like this:

Now it has changed to this:

As you see now the title has additional parts such as required or field. This means that you haven’t in this attribute the display name of the field alone and you will fail if you query by title.

Safer approach to request fields

As mentioned before the ID property is the only one that is unique in the whole page. The ID is formatted in the following form:
Field name + ”_” + Guid of the field + ”_$” + Type of the field.
As seen in the previous section the ID looks like this:
Region_59566f6f-1c3b-4efb-9b7b-6dbc35fe3b0a_$LookupField
So if you like to be absolutely sure and like to generate this ID by yourself you need to do a request to the list and read the fields. The you will be able to find the name by the display name, the id and the type. This will make some lines of code that you can reuse in your projects. I haven’t seen any ready made code yet but I’m sure it can be found somewhere over the internet. (If you have would be great to post that in the comments)
I looked into this problem and what I found was that SharePoint does that job for you and stores it on the form in the JavaScript variable “WPQ2FormCtx”.

Console output of WPQ2FormCtx Object

Console output of WPQ2FormCtx Object

This context is somehow new in SharePoint 2013 and Office 365 This somehow represents the so called form context with a lot of information. Also included in this variable is the list schema which we can use without loading any additional information from the list.
So what I did is that I created a small javascript object that loads the information and allow me to generate the id of the field. The tricky part i currently not have implemented is the type part because this is a little bit tricky and the value changes with the different configurations of the fields. I hope that the following code give you an example how this works.

To this script the last part needs to be added to be 100% sure. Think about the fill in option for example this will start with the same id but I’m sure there will be added a special type.

Field after update via JS

Field after update via JS

As you see the value was written to the form

A Look to the future

I will never use the title field again. I write this now 100 times to keep it in mind. But not here in this blog post. In future I will reuse my little helper object for a simple reason. If Microsoft changes the format of the ID attribute I only need to change it at a central location instead of search and replace all my jQuery / JavaScript code.
Convenience is not everything better go an extra mile to be safe.

  • Stefan:

    Great detective work.

    I’ve actually got just one line in all of SPServices to find selects like this. It’s in a constructor function called DropdownCtl. I use that constructor to find any type of “dropdown”, meaning a simple select, a “complex” select, or a multi-select. Due to the oddities in SharePoint forms across the versions, I long ago realized that I needed to handle those oddities centrally.

    In fact, I’ve written before about how inconsistent the multi-select controls are in Variations in Multiselect Controls in Different SharePoint Language Versions. Because of these inconsistencies, I have special logic for Russion, German, and Italian, where the element naming is just different enough to be a problem.

    If this recent change is intentional, then I’ll update that function to handle it. I’m going to guess that it wasn’t intentional, though, because except for a tiny UX improvement – and even that is debatable – there’s no discernable purpose to the change that I can think of. The bigger problem is that it just happened, and there’s no way to see these changes coming.

    BTW, the ‘ Required Field’ text only appears in the Title attribute in simple and complex dropdowns (not multi-selects) when the column is required. I have no idea what might appear in sites where other languages are used, but based on my findings with the multi-selects in the past, all bets are off.

    M.

  • FYI – I’ve talked to someone in the PG and they are looking into this issue. I’ll post details on my blog post Office 365 Update Changes ‘Display Name’ on Required Fields as I get them.

    M.

  • Jon

    Nice post and I agree “better go an extra mile to be safe”. I have done a similar thing and wished I had just spent the extra time on it.

  • I’ve come up with that I feel is a very reliable method to select on the id using regex. Take a look at my post
    Regex Selector for jQuery by James Padolsey FTW (http://sympmarc.com/2014/02/05/regex-selector-for-jquery-by-james-padolsey-ftw/).

    In the latest alpha, I’ve also made my internal function a public function called $().SPServices.SPDropdownCtl. My hope is that I can keep the function up to date as Microsoft changes things going forward.

    M.

    • Stefan Bauer

      Great to hear Marc!
      I surly will take a look into that post.
      Thank you for the Update
      /Stefan

  • Mdmazzotti

    There’s one thing I’ve always wondered, because I can’t be the only one having a multi-language SharePoint installation.
    In a site where you’ve enabled more than one language (say, English and Italian), you can configure the fields of a list to be localized according to the current selected display language. This affects the title property, basically breaking all jQuery code that relies on that.
    How would you handle this? The issue applies to both SharePoint on-premises and online