I want to create footer links inside my master page, and I was wondering what's the best approach to achieve this, do I create a SharePoint List to store my lists and embed it as a list and change its look using JSLink?
What are the pros and cons about this approach? Or do I use server side code and use caching to create this section? Any recommendations?
I would go for a User control with server side code. The UC can read from a list you (or the user control itself) creates and then create HTML from that result. You can then style the HTML with CSS if needed
I would use HttpCache or similar to cache the final HTML for as long time as you think is viable for your use case (note that an IISRESET will clear the cache) to get great performance and low stress on the server.
The user control can then be added to the master page directly or through a delegate control depending on wether or not you have a custom master page.
As I suggested in a comment to another answer, there are numerous ways to accomplish this that don't involve deploying server-side code into SharePoint. Here are a few that I could think of, I may have left some out; each have some advantages and possible challenges.
TL;DR: Use the JavaScript injection pattern (especially with SharePoint Online - -- this is the current Microsoft Patterns and Practices team recommendation) unless you need to do heavy re-branding in addition to adding footer information -- in which case I recommend customizing an existing SharePoint master page or creating your own. Just remember the custom master page route involves some expense in up-front and future effort on your part.
Edit: Chris O'Brien recently published a timely and more thorough blog post about customization issues in general (since they have been evolving over the past couple of years) over on his blog that does a fantastic job of explaining some of these choices while discussing the decisions the SharePoint team have been making as well as those that developers and designers should be making: http://www.sharepointnutsandbolts.com/2015/01/custom-master-pages-and-web-templates-in-office-365--thoughts.html
Now for the details of some various approaches:
How it works: Create JavaScript that injects your footer markup and any other supporting styles onto a page. Use an App or solution to deploy the JS asset programmatically to the host web using CSOM/JSOM, then add the script to the site's custom actions so that it runs on each page load. See a rundown on this technique from Andrew Connell here: http://channel9.msdn.com/Blogs/Office-365-Dev/JavaScript-injection-in-SharePoint-Online-Office-365-Developer-Patterns-and-Practices
Advantages:
Status notificationsDisadvantages:
Relies on page markup that you may not have direct control over
More complex to setup and update than other solutions
Updating content inserted this way requires an update to the source script (some dev/designer intervention needed) Possible to implement a service call to pull the information from a list or file source in a library; this introduces another HTTP Request into the process (disadvantage) but would allow for simplified editing by end/power users (advantage) and allow the page to render and become usable before all the content was retrieved from the server since standard JS data retrieval methods do not block the UI thread (advantage)
How it works: Use seattle.master or oslo.master master pages as a starting point and make modifications to copies of them to suite your specific branding/content needs (you should not modify these master pages directly). Upload your version of the master page to your site collections. Reference this page as the master that should be used in your site settings. For more information, I suggest: "Master pages, the Master Page Gallery, and page layouts in SharePoint 2013" on MSDN; SharePoint 2013 Branding and User Interface Design by Randy Drisgill, John Ross and Paul Stubbs; and Pro SharePoint 2013 Branding and Responsive Web Development By Eric Overfield , Rita Zhang , Oscar Medina , Kanwal Khipple
Advantages:
Disadvantages:
How it works: There are some options in how to approach this, but typically you would start by making a regular HTML page that looks like you want, then convert your HTML file into a SharePoint Master page then proceed as in the edited master page description. See all of the resources listed for customizing the built-in master pages for way more information from people who know a lot more about this than I do!
Advantages:
Disadvantages: Same as disadvantages for "Modified SharePoint Master Page / Page Layouts" but with added complexity of building the entire design yourself.
How it works: Create a text or HTML file that includes all of the markup you want to place in your footer area. Add a Content Editor Web Part to each page where you want the footer to appear and reference your text or HTML file as the content source. You'll need to include appropriate styles with the content (in a <style> tag, for example) or somewhere in your own CSS style sheets.
Advantages:
Disadvantages:
How it works: Insert a Content or Script Editor WebPart on each page you need your footer information to display. Instead of defining an external source (as in the previous example) define the markup/script contents directly in the web part source via the web part editor dialog.
Advantages:
Disadvantages:
How it works: Allows you to specify a custom master page and color scheme that an end user can apply to their site and customize under "Site Settings" > "Change the look" (see this Office how-to article for more information). Setup is a bit laborious, so I will just provide a link to the relevant MSDN documentation on the subject.
Advantages:
Disadvantages: There are a number of disadvantages that are well-covered by Heather Solomon at http://blog.sharepointexperience.com/2013/05/when-to-use-a-sharepoint-2013-composed-look/ as well as better instructions than I have given for how to set this all up. To summarize: the changes they make are difficult to manage in large environments, users are allowed to specify their own background images and color schemes (problem for many designers out there), the solutions are difficult to debug, and you need to re-create your master page design to generate the .preview files but there are enough differences in the formatting and component use to make this a chore (you need to almost repeat yourself... but not almost enough to copy and paste...).
A note on caching and performance: SharePoint is an ASP.NET application under the covers, and ASP.NET in general and SharePoint specifically have a number of tricks for caching the results of most outputs, to include: page outputs, list contents, query results, and large amounts of binary information (such as videos and other file types -- note binary large object (or BLOB) caching is not enabled by default, it must be turned on by the farm admistrator). You can find a MUCH more thorough explanation of the caching options within SharePoint over at Microsoft's Technet site; here is a particularly good article on the subject. These settings cannot be as fine tuned as something like a farm solution using the server-side object model, but they do offer a mature, well-tuned solution that applies to your entire farm and will suffice for the vast majority of content your SharePoint installation delivers.
The reason I mention any of this is to clarify that SharePoint already has many mechanisms for improving performance through caching; it's not really required that you implement a farm solution to have a performant solution when it comes to customization.
I would also add that performance and the perception of performance are two different things. A web page that waits for a bunch of webparts to render on the server will typically be percieved as having much worse performance than a page that makes a bunch of AJAX calls to load the content without blocking the UI, even though the page using AJAX may actually have taken a longer time to complete its work.
Something important to remember for any solution involving JavaScript; you need to remember to make sure your script can handle Minimal Download Strategy (MDS) environments -- this adds a bit to the complexity of the solution, but does greatly enhance the overall experience for 2013 and SP Online sites.
I'm certain I've left out many of the problems and possible mitigating techniques to use for each approach, feel free to add to those that you notice.
Since you are using SharePoint 2013, you can either use JSOM or REST API to read the data.
This is happening on the client side, and it will be easier to add it to respective DOM elements (or create new elements).
JSLink is a good option, but implementation will take more time. I prefer REST as it's much easier to implement and performs better.
JSLink the same thing will happen. I don't think there will any performance impact. I have used this approach on multiple projects and no issues so far.
Jan 5, 2015 at 18:25
HTTPCache going forward. But this require serverside coding and as you know Microsoft is discouraging those. Also styling the footer using server side controls will be tricky.
Jan 5, 2015 at 18:32