SharePoint Framework

去年の暮れぐらいだったか、MSのお知らせでSharePoint Frameworkという新しい開発環境を使った SharePoint SiteのCustomizationが可能になりました。という連絡があった。  自分がやりたいSPサイトのCustomizationは 基本的にJavaScriptをページに埋め込むJavaScript Injectionという手法だ。 これでクライエントサイドの描画をコントロールするCSRフックとかリストやファイルのアイテムをAjaxで読み書きするREST APIなどを使ってカスタムページを作るという方法で用が足りてしまうので、あまり気にしていなかったのだが、この方法、最近、その進化が目立つModern view  pageでは使えない。 これは開発するのにVisual Studioが必須であるSharePoint Add-Inでも同じ様で、 どうも今の時点でModern Look componentのCustomizationをサポートしているのはSharePoint Frameworkのみのようなのだ。

で、Dev.Office.comのDocumentationを眺めてみると、なんとこれ、 Node.JS上で全部動いているのだ。

NPMで yo,  gulpと @microsoft/generator-sharepoint を導入し Project folderを作って以下を実行

yo @microsoft/sharepoint

これで必要なファイル群がフォルダーにインストールされる。 hello worldのテンプレートになっているので、これでもうnode.js 上のローカルPCで動くSharePointのページを模したWorkbench上での実行が可能(下記コマンドでDefaultブラウザが勝手に立ち上がる)

gulp trust-dev-center

gulp serve

ここまで、SharePointサイトにアクセスする必要すらない。 Step by Stepはdev.office.comに詳しいので割愛 (Build your first SharePoint client-side web part (Hello World part1)

SharePointのサイトでもすでにDevelopper siteが例えば”https://mysite.com/sites/dev”などとして設定されているなら、 ”https://mysite.com/sites/dev/_layouts/workbench.aspx” にアクセスすると、開発中のwebPart のWorkbenchがSharePoint上で作動する。

そしてこのTool Chainによる開発、Visual Studioが必要ない、というか使えない。dev.office.comのお勧めEditorはVS Code. IDEの例としてJetBrainのWebStormがあげられているなどVisual Studioへの依存性が一切ない。(C#もドットnetも使わないなら当たり前というべきか)

ただ、使われているコードが通常のJavaScriptではなく、TypeScriptなのだ。 TypeScriptのコードは実行時にはJavaScriptにばらされるのでそんなに大きなLearning Curveにはならない、と予測はしているのだが、これは学習する必要があるんだろう。

Node.jsは言語というより開発環境のベースとして使われるので、これ自体を学ぶ必要はない。

VSで使っていたNugetだとかMS buildーtoolなどのツールが、下のようにNode.JS上で動くツールにおきかわっているわけで、今わかっている範囲でまとめると

  1. Node.js: Install するだけ、普通のJavaScriptの知識で十分のはず。
  2. NPM :DependencyのUpdateなど、使い方は学んだほうがよさそう。yarnでもいいのかな
  3. yeoman(yo):Install するだけ、学習の必要性はなさそう
  4. gulp: コマンドをいくつか覚えるだけで学習の必要性はなさそう
  5. typescript: 学習の要あり
  6. webpack:@microsoft モジュールを導入したときに含まれている。さわらなくてよい。何本ものファイルを、一本に圧縮する、というような作業をやっているらしい。
  7. VS CodeまたはWebStorm:Dev.office.comはVS Codeを使った用例を挙げているが、自分は従来からつかっているWebStormを使う。

というわけで、なんと開発環境的には、2,3,4,5,6は1のNodeJSが動けば動くのでなんでもよく、VS codeもWebStormもマルチOS環境で動くので 要するに Linux上で開発できてしまうのだ。

というわけで、javaScriptをかじっている人間にはハードルが低そうな予感。 Linux環境でぼちぼちやってみようかな?

exploring SharePoint Online

Our office is soon moving to SharePoint online. Currently we are using SP2007 and Microsoft does not support content migration from 2007 to 2013 or SP online. This is good and bad. Good because we can build sites from scratch, bad because there is no easy way to move our contents from SP2007 to SP online. We should be able to copy files and folders from 2007 to online but all the metadata will be lost. lists will be even tougher. we have the third party solution called ShareGate but IT guys are telling us it is faily slow we can not possibly migrate the whole sites (that is in the size of the order of Terabytes.) and would like to selectively use the tool. Document Management is tricky under the SharePoint at best.

UI has been greatly improved. It is now much easier to interact with contents with JavaScript. I am having tremendous fun with technique like CSR (client side rendering) and REST API that can be used with CSR or as a conetnt of CEWP as usual.  Furthermore , attaching JavaScript code to web part is made less painful by the introduction of JsLink option and inclusion of script web part.

It is also good to have started late in the game. Internet is filled with power user tips. (I can use most of the technique meant for SharePoint 2013 with SharePoint online.)

One of my favorite technique called “calculated column” is still possible with much less hassle.  Again CSR can be used for this with literally one line of code.  Even better, I can forego with calculated columns at all and directly manipulate the target columns and show bar graph or traffic signal instead, using CSR’s context override.

Filter/connection of WebParts on the page is now performed on the list and not view. In another word, the filtering column do not need to be a part of the view.  This is tremendous for me. I no longer need to hide a column that is used for my filter because I don’t need to include the column in the view to start with.

EasyTabs that we used and found so useful for SharePoint 2007 does not work as is.  Again somebody has modified it for SharePoint 2013 and it is  working. Christophe seems to have developed another tool package that includes EasyTabs functionality but my inquiry to him went unanswered so I am using this version.

There is another code called Hillibily Tabs which essentially do the same thing as EasyTabs.  This one uses jQuery and jQuery UI (and CSS) to manipulate the tab, so how do I say this..  It’s flashy and probably more maintainable.

Excellent write up on CSR by Andrei Markeev is here be sure to check other articles by him.

This one by Kaptyn is also good

Many CSR examples are on Office Dev Center, uploaded by Muawiyah Shannak.

The above examples contains calculated column like effect witihout using the calculated column.    However, if you insist Calculated columns to be used, here is Christoph’s explanation of how it can be done.

List Roll up

I was first thinking maybe we need to purchase third party package to do this.  It turned out this is doable with home made JavaScript code with REST API. I am able to Roll up the list (read only at this time, because I only feel comfortable with “GET” potion of the API) in my sandbox, using a couple of sub-sites.  I will try and see how scalable this technique is.

Minimum Download Strategy

Sooner or later, people will hit this “MDS” *issues*  where the view changes back to its default look when switching the view,  or code breaks because it can not find jQuery that was supposed to have been loaded.  I am still learning this but found some blog entries very helpful.

  1. Article by Kalmstrom.com talks about what happens with MDS in very short text and also give pointers to how to deal with it
  2. SharePoint 2013 – A Better Pattern for Client Side Rendering Scripts shows a script pattern that can be used for site with or without MDS feature enabled.

However, my observation is that once you introduce your own code to the mix, then SharePoint engine with MDS seems to try render first with MDS way, then try to render again for “foreign” code.  Because of this, some of the pages does load faster with MDS off.  So turning this feature is not as bad as it may sound.

 

Most of the link here are from various blog entries.  Again, it must be much easier now than two years ago to find the information I need.  MSDN also have many documents I can refer to but there coverage is broader (C#, XML ,.aspx and JavaScript code).  As a business side power user, I (can) only use JavaScript and find those individuals’ entries priceless. My appreciation goes to those who spent many nights to figure out and then took a time to write about it!

SharePoint online :: modifying “New item or Edit this list” to “Edit this list”

This is my first “SharePoint Online” related javaScript.(I am still experimenting with nuance of SP online)
This script changes “New item or Edit this list” links to simpler “Edit this list link.


/**
* Created by A2life on 3/24/2016.
* Modify new or edit div to "edit this list" only
* modify "New items or edit" elements on entire page (not just webPart this is attached to)
* */
(function () {

var thisContext = {};
thisContext.OnPostRender = modifynewEdit;
SPClientTemplates.TemplateManager.RegisterTemplateOverrides(thisContext);

})();

function modifynewEdit() {
// jQuery library is required in this sample
// Fallback to loading jQuery from a CDN path if the local is unavailable
(window.jQuery || document.write('<script src="//ajax.aspnetcdn.com/ajax/jquery/jquery-1.11.3.min.js"><\/script>'));

jQuery("td.ms-list-addnew:contains('new')").each(function (index) { //only respond to "New" elements
var edit = $(this).find('a:contains("dit")'); // because I am looking for "[E|e]dit"
edit = edit.text("Edit").add("<span> this list</span>"); // reconstruct link with proper words
$(this).html(edit);
});
}

attach this to list webPart as jsLink parameter. If uploaded to Site Assets folder as “modifyEdit.js” , it should look like “~site/SiteAssets/modifyEdit.js” . “~site” is a token for the site that sharePoint uses to resolve the url reference.

Note on this code.

  • The document.write line dynamically writes a script tag for jQuery. This appears to be more reliable way of loading jQuery rather than referencing to the file within script tag.
  • The code creates a context override for onPostRender SP event for the webPart (of item list view) being attached. This event seems to fire even when other list view on the same view is changed  (and the code invoked will affect other list views on the same page as expected) so the function modifynewEdit is attached to this event.