1

All samples and documentation I've red about JSLink shows that the field name must be known in the script file (ex: https://github.com/SharePoint/PnP/blob/master/Samples/Branding.JSLink/Branding.JSLink.NCSS/Style%20Library/OfficeDevPnP/Branding.JSLink/TemplateOverrides/FavouriteColours.js)

It's ok when the jslink is dedicated to a specific field or list, but what about if a common behavior may be plugged to any field ? Especially if I want to add a common behavior to a field itself.

Should I put logic in separated files and a set of jslink to plumb the logic (with hard coded jslink names) ?

Is there a way to know which is the field where the jslink file is registered ?

1 Answer 1

1

These scripts run at page load, and are bound to a field at render time. So you have to know what field in the code is being overridden.

So your suggestion about separating the behavior code from the field names is the best approach that I have come across.

By listing the JSlink files in the right order, your names will be declared first, then a modification to Martin's code to generate the template override object based on that names object seems to me the best approach to have some dynamic nature to it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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