Although the benefits are awesome and obvious, the presence of client-side templating is rare in the SharePoint space, I don’t see it very much. I don’t even hear it talked about often. Let me say that I’m not dissing any one. I’ve been known to revert back to server side web parts in a New York minute. I think several SharePoint developers do the same. It’s because that’s what we’re comfortable with. It’s what we’ve done in SharePoint for years and it works over and over again. It’s like tradition! But a wise man once said “It’s also a tradition that times must and always do change my friend.” [2 bonus points to whoever can name that movie!]
So, the first thing you need to decide is what templating engine you want to use. There are several choices to choose from. All have their pros and cons. But the one templating engine that I’ve fallen slap-happy in love with is Handlebars. Again, it has some drawbacks but it’s incredibly easy to learn and the syntax just makes sense. My demos will all use Handlebars.
1) Data source
In this series I’ll cover a few different data sources:
- In Part 3 I’ll cover the very exciting SharePoint Search REST API. This will allow us to pull data from multiple lists and libraries within SharePoint.
- In Part 4 I’ll dig into getting business data that doesn’t live in SharePoint. You’ll want to stick around for this one.
2) Data Retrieval
3) The Template
This is the actual HTML that you want rendered. After data is retrieved we’ll bind it to our template to fill in the placeholders with useful information. Sounds kind of complicated on the surface but Handlebars makes this part easy.
One added layer of complexity with developing in SharePoint (or any CMS for that matter) is the need to encapsulate your component and make it modular. Unlike traditional development, you have to keep in mind that the user should ultimately be in control of what page and where on that page your template should live. Sounds like a web part to me! Technically you could bundle your template and the code for your ajax call in the html of your web part. But before you get too excited, please don’t. For ease of debugging and hygiene purposes, I recommend separating them into separate files.
Now that you have a foundation, let’s dig in. Stay tuned for the next post.