2

I want to hide some fields from my Edit & New forms, and i need this to apply to all the subsites. now if i hide the columns from the Content type they will appear again when users modify these columns from the list settings. so i need a way to hide them using scripts, to make sure they will never appear. so what i did is that i create a js file and i save it inside the Style library on the site collection level:-

$( document ).ready(function() {

$('.ms-formtable nobr:contains("Item Number")').closest('tr').hide();
$('.ms-formtable nobr:contains("Customer Initials")').closest('tr').hide();
$('.ms-formtable nobr:contains("Recurrence")').closest('tr').hide();
$('.ms-formtable nobr:contains("Workspace")').closest('tr').hide();
$('.ms-formtable nobr:contains("All Day Event")').closest('tr').hide();



});

then inside the New & edit forms i add a reference to the above script,, which hide the columns successfully.

but my question is if hiding columns using standard javaScript is the formal approach to use ? or i should be using something such as jslink ?

So I have these main questions:-

  1. what are the differences between using standard javaScript & between using JSLINK . and which is the formal and the recommended approach to follow for hidding columns?
  2. is it easy to convert the above script to be expressed in JSLink ?

Regards

9

First, let's just clarify that JSLink is not equivalent to Client Side Rendering. JSLink is merely a property on SP objects that lets you attach Javascript files to them.

However, the ability to attach a Javascript file to a SP object is enormously useful for CSR. Using the JSLink property is one of the easiest ways to apply CSR.

And I would say that since CSR is the way SP itself renders things, and MS has exposed this mechanism and enabled you to use it to override the default rendering, then CSR is the "formal" way to do things like hiding columns.

In your particular case, using JSLink/CSR could be very useful. You say you want the fields to "never appear" in new/edit forms. The SPField object has a JSLink property, so you can attach some CSR code to each field. Then the code travels with the field wherever it goes, meaning, even if your users create a new custom content type with one or more of those fields, your rendering overrides will still be applied.

This would mean that you would have to break up that code into one file for each field. The CSR code for one of the fields would look something like this:

(function () {

    var overrideCtx = {};
    overrideCtx.Templates = {};
    overrideCtx.Templates.Fields = {
        // need to use the internal name of the field here
        "ItemNumber": {
            "NewForm": formFieldOverride,
            "EditForm": formFieldOverride
        }
    };

    SPClientTemplates.TemplateManager.RegisterTemplateOverrides(overrideCtx);

})();

function formFieldOverride(ctx) {
    // get the span that represents the field's actual edit control
    var span = $get(ctx.FormUniqueId + ctx.FormContext.listAttributes.Id + ctx.CurrentFieldSchema.Name);

    // still need to go up two levels to hide the entire <tr>
    span.parentNode.parentNode.setAttribute("style", "display:none");
    return "";
}

That being said, I see you have fields listed like "Recurrence" and "All Day Event", which look suspiciously like default SP calendar event fields. I don't think you'd want to attach a CSR file to one of those fields that hides it in the new/edit forms, because who knows, you might want to set up a calendar some day that allows you to have recurring or all day events...

For more information on CSR in general I recommend these two articles:

Client Side Rendering: List Views

Client Side Rendering: List Forms

Also, here is an article that describes how to hide fields in forms using basically the same jQuery technique you used, but applying the jQuery through JSLink/CSR rather than running the code on $(document).ready().


To answer your questions from your comments:

You asked what is the "formal" way to do these kinds of things, and I'm just arguing that because SP itself uses CSR as the way it renders things, then using the same mechanism to override the default behavior could be considered the "formal" approach. That does not mean using jQuery in a Script Editor web part to manipulate a page is "bad practice", in fact it is a very common practice, and I use it too, depending on what I am trying to accomplish.

You just have to think about what it is you are trying to do. If you stay with what you have already, the custom rendering you are doing (hiding the fields) will only apply to that page where you have added the script. If that's enough, then you're fine. But, if you want the custom rendering to be more widespread, then there are other ways to accomplish that, so you don't have to go and add a script editor web part to every page where you want the fields hidden.

Think about it: if you want a field to be hidden on every single new/edit form, no matter what, then every time a user makes a new list and adds that field, you are going to have to know about it and go and add a Script Editor web part to that form page, and add your script. That's a lot of work. Unless... you use JSLink to attach a CSR script to the field itself. And yes, it will apply to everywhere the field is used if you attach it at the proper place. If you have a custom field defined as a site column in the root site of a site collection, and you attach the CSR script at that level, then it will apply to anywhere that field is used throughout the site collection. However, if you have added the field to a list, and you attach the script to the list level copy of the field, it will only apply to that list.

Similarly, if you have a custom content type that uses that field, and you want your custom rendering to happen only when that content type is used, but you don't care if the custom rendering is applied if someone uses the field outside of that content type, you could create a CSR script that applies to the field, but attach it to the content type. And again, if you do this at the site collection level, it will travel with the content type and will apply anywhere it is used in the site collection.

So there's really a lot of options and a lot of possible behaviors, you just have to figure out what exactly is the behavior that you want to see, and figure out the best approach to get that. Like I said, if all you care about is hiding the fields for the new/edit form for that one list, and you have it working already with the Script Editor web part, then you're done. If you did want to change it to a CSR script, and still only have it apply to that one list, then you can do it easily because the List Form web part has a JSLink property (you can see it in the "Miscellaneous" section if you edit the web part).

As far as how to set the JSLink property and attach CSR scripts to fields and content types, take a look at this article that shows examples of how to do it through server side code (if that's an option for you) or Powershell.

  • thanks a lot for your detailed reply,, so using CSR is better than using jqyery as it is more formal and SP-oriented.. but now i add the jquery by editing the forms , then i add a web part of type "Script Editor" , after that i write the jquery.. so my question is how i will be adding the JSLINK/CSR is it in the same way ?or i will have to use Visual Studio ? second question,, is using a standard jQuery to hide columns as i am currently doing consider a bad practice , or it is just not the best approach to follow ? – john Gu Jun 4 '15 at 11:15
  • third question, you mentioned if i use JS link to hide column then the column will be hidden on all the forms even for new sites,, which is not the case.. so i need to apply the script to related forms only so i might use exactly the same approach as mention din the link you provide code.msdn.microsoft.com/office/… ?? – john Gu Jun 4 '15 at 11:23
  • 1
    @johnG, updated my answer to answer your new questions. – Dylan Cristy Jun 4 '15 at 14:56
  • thanks for your great reply.now after reading about this topic i realize that what i need is to set the site column as hidden inside the following; quick edit grid& edit form & new forms. but to apply this settings to the site column at the content type level , and not to the site column itself.. so that in the future if i add the site column to a new site content type then i will not have these settings. so my question if you can provide some usful links on how i can apply hide on edit & hide on new & hide on quick edit , to the site content type ?? – john Gu Jun 10 '15 at 10:14
  • @johnG, I'm not sure how to hide it on quick edit, I have seen your other question about that and I can't offer any insight. But, as I mentioned in my update to my answer, you can take the template override code that hides the fields, and instead of attaching the Javascript file to the field's JSLink, attach it to the JSLink of the content type. That way, the code travels with the content type, but the code affects the fields. Does that make sense? – Dylan Cristy Jun 10 '15 at 12:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.