When you write a new web part with the SharePoint Framework you might create a genius web part, where all the business logic is compiled into your web part. This approach makes sense when the web part is an isolated piece of work.
Sometimes you like to write pretty simple web parts that only access a backend or third-party API from somewhere on the Interweb. In this case, you can write all the data access inside your web part. Give the user the option to store APP Key, APP Secret and particular access token directly in the web part. Might pre-populate some of those properties of with your company-wide secrets and API keys too.
I guess I showed in some of my recent blog posts that it is possible to test themed web parts during development. This theme testing is currently not possible in the local workbench, but it is possible on the one available on Office 365. Let me show in this post how I did and do and in which problem might occur to your web parts too.
While I was looking at the new SharePoint site content page I asked myself if more can be found that gives an indication of the upcoming framework and future improvements.
First, I took a look at the source code. Not a big surprise the page was built again using Facebooks ‘React‘ for the user interface and ‘Knockout‘ was used for data binding.
After that I came up with the idea to take a closer look at the web part gallery to see if might some web parts have been deployed to. To my big surprise I found overall five new web parts.
Web Parts of the new SharePoint Framework Extension
While some web parts are used to provide tips and trick or how to get started. Two other web parts are more interesting.
The ‘Embed Video Web Part’ and the ‘Embed picture library web part’. I populated them to the gallery and added them to a page in SharePoint. Currently they are deployed, but sadly not working yet. There are no web part specific properties to be configure now and I guess they current won’t load any additional Script or CSS.
New webparts embedded on page
Embed video web part makes sense to me because this is currently handled by a script embedding web part. A web part that is not responsive without customization.
The embed picture library web part is more interesting because the description states that you can use this to create a fancy new slide show.
In addition to those upcoming web parts it is likely that the new namespace of the additional framework will be ‘Microsoft.SharePoint.SPX‘.
It is great to see at least a glimpse of the upcoming changes and how the new user interface will be built. Waiting until autumn is still such a long way to go. Especially if you use the same mechanism to customize SharePoint for at least two years now.
Let’s hope it will be released sooner than later. I guess many people love to get their hands on it and provide feedback. Even if it is not rock solid yet.
If you are not so familiar with things like Yeoman, Angular, ReactJS, Handlebars or Knockout, please check out some really great web casts done by the Office PNP team.
A couple of weeks I was contacted via twitter about my blog post that shows how to bind JSLink override to certain web parts only. Jared Matfess (@jaredmatfess) tried my script and recognized that somehow the paging of the web part was broken. I dug deeper into this issue and found the cause of the problem. It seemed that the way how I showed the View ID was the origin.
The “Modified”, “Modified By”, “Created by”, “Created” cannot be accessed directly via the SPView object because this simply doesn’t store that kind of information. To request this information the SPFile object needs to be used instead.
Customising form works great as long as you have a single list and a single form in your portal. If someone saved the list as template and created new instance, the problem start to begin when something needs to be changed in the form.[Read more]
Imaging the following situation where you want to export an XSLT List View web part and embed it on a different site. So the good thing about this it’s easy to accomplish. I came across a great article posted by Glyn on his blog how to export an xslt viewer web part. He shows in his article some really great insight how the xslt viewer web part can be exported. The only thing he left out is that you can export XSLT List View web parts using SharePoint Designer. This feature is really well hidden in the ribbon.
In SharePoint Designer simply select the XSLT List View web part you want to export. In the Ribbon you will find a specific menu for this web part. Ribbon for the web part comes up you can select inside the “Web Part” Tab. In the far right area of the ribbon you will find two really helpful menus.
The “To Site Gallery” option will copy the web part to your site collection web part gallery. You will also be asked how you want to name your web part, description and you will be able to change properties.
Another option to select is if you want to use it relative to any site where the web part will be embedded or get data only from the current site.
The “To File” option will open the download dialog to store the web part and the configuration to a file.
As you see it’s easy to export a XSLT list view web part and use it the way you like. You can also cross embed lists from one web into another.