SharePoint 2010 introduced CSOM as a new way to create client side application. It was a quite nice step forward which allows creating “light” client side applications and minimize farm downtime. With the latest SharePoint 2013 trends – html/js apps – it is worth to utilize CSOM even more intensively for your “old” SharePoint 2010 projects. However, some common routines to deploy and deliver your js-based/CSOM app to SharePoint are still required. Here are some ideas how it could be addressed
Geting started with jsAppWebPart
Basically, that topic was covered in the previous post. So, to get some context about jsAppWebPart, you may check “jsAppWebPart for SharePoint 2010 – one more way to craft a js based apps, part 1” post. This post covers the Visual studio/wsp package approach to create a repeatable and smooth experience with deployment and delivering apps for the jsAppWebPart. Let’s get started.
Visual studio/wsp package approach
Surely, have a repeatable and smooth deployment experience with wsp package is a good thing. To pack your app in the wsp package, simply create a new SharePoint Solution via VS. There is no need to make a farm solution, so sandbox solution could be a better option. Also, it will not require any c# coding at all! Cool, huh?
So, add a new module with an appropriate name, add js/html/css files:
Finally, correct the url paths in the Element.xml to deploy your file to the right folder. For our app, Element.xml may look like this:
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Module Name="HelloWorldApp" Url="jsAppsLib/apps/Hello world app">
<File Path="HelloWorldApp\app.meta.htm" Url="app.meta.htm" Type="GhostableInLibrary" />
<File Path="HelloWorldApp\app.meta.png" Url="app.meta.png" Type="GhostableInLibrary" />
</Module>
<Module Name="HelloWorldApp" Url="jsAppsLib/apps/Hello world app/1.0.0.0">
<File Path="HelloWorldApp\1.0.0.0\app.css" Url="app.css" Type="GhostableInLibrary" />
<File Path="HelloWorldApp\1.0.0.0\app.js" Url="app.js" Type="GhostableInLibrary" />
<File Path="HelloWorldApp\1.0.0.0\app.htm" Url="app.htm" Type="GhostableInLibrary" />
</Module>
</Elements>
The last step is just deploy a wsp package via Visual Studio, PowerShell, SPSD or uploading it manually via web interface. That’s it. Enjoy!
Apps versioning
As it was mentioned before, jsAppWebPart has its own versioning features for the apps. It leverages the mane convention over the folder name. Also, the web part automatically utilize the latest version it can find under the application folder. So, to add a new version of js apps, simple create a new folder with new version number and add new content as on the following screen:
CDN folder, SOD and custom script loading/loader
Well, it turned out that SOD is not that good to load a custom js scripts. Actually, you need to modify every script with “” function call to notify SOD that the script has been loaded. It is okay for your custom scripts, but isn’t very nice ideas for such a scripts like jQuery or KnockoutJS.
To address that, people have come with implementing custom js script loader. It allows to load any custom scripts (even from MS CDN from the internet), but also requires a little bit effort to be in synch with SharePoint’s SOD. More explanation and context could be found here - SharePoint 2010 Script On Demand–give me my scripts right now!
So, that’s why jsAppWebPart comes with custom custom js script loader to allow you load any script without SOD. The implementation could be found at “jsAppsLib/sys/core/1.0.0.0/app.js” file.
It is in early demo yet, so it could be changed in the future.
Extensibility
Making up any “common infrastructure” is not an easy thing. As business requirements are different, it is necessary to have an appropriate level of extensibility to be able to meet the requirements.
Currently, jsAppWebPart doesn’t have any extensibility except inheritance and overriding several methods to customize the toolpane, tokens processing, adding any new behaviour. Also, sandboxed solution has its own limitation and impacts.
Anyway, at this very moment jsAppWebPart is just a proof-concept and the future development is not clearly known. However, there are some ideas described at the “Future road map” section. Also, would be nice to hear any feedback or ideas from the community.
The road map
Currently, jsAppWebPart is a proof-of-concept project. However, there are some ideas to work out and see how they would look and work like.
“Application repository” and “application picker.
This feature was already implemented and described in the post. The idea is to have a centralized way to store and deploy js based app, to provide a consistent UI for the end user.
Application version picker
jsApWebPart has built in “versions” for the js apps. Bu default, the latest version of the app is used. However, it would be nice to be able to select the target version of the application via app picker.
Application properties
It would be nice to have not just app picker, but also app propertied grid/settings. It could be a json object to be serialized as a part of the web part definition/property and passed/available to js app via token.
Caching and better persormance
As html content of the application is something what isn’t changes frequently, it could be cached/precalculated to avoid fetching/token processing.
Custom tokens
It would be nice to be able to extend built in tokens with custom one. Implementation is quite unknown yet, but possible.
Links
- jsAppWebPart for SharePoint 2010 at codeplex
- jsAppWebPart for SharePoint 2010 – one more way to craft js/CSOM based apps, part 1
- jsAppWebPart for SharePoint 2010 – one more way to craft js/CSOM based apps, part 2
Conclusion
CSOM, sandboxed solutions in SharePoint 2010 and the “new apps” model in SP2013 are really nice things to be explored and utilized. Making client side apps with html/js/css has a lot of benefits such as simplified development and deployment, maintainability and minimal impact/downtime on the target SharePoint farm.
However, it still might require some SharePoint related coding – web parts, modules, feature receivers and the rest. To minimize these activities, some common infrastructure could be done. It could be “generic web part” which implements some routine functions, it could be set of js/html/css scripts or file, or it could be even bigger projects like jsAppWebpart.