SharePoint Framework 概述

Justin-Liu發表於2016-10-06
部落格地址:http://blog.csdn.net/FoxDave

本文翻譯自新出的SharePoint Framework概述介紹文章,原文地址:http://dev.office.com/sharepoint/docs/spfx/sharepoint-framework-overview

注意:SharePoint Framework目前是預覽版,會隨時更新,目前並不支援在生產環境使用SharePoint Framework 客戶端Web部件。

SharePoint Framework(SPFx)是一個頁面和Web部件模型,它提供了對SharePoint客戶端開發的全面支援,能夠輕鬆地整合SharePoint資料,並支援開源工具。通過SPFx,你可以從一開始就在你偏愛的開發環境中使用現代的web技術和工具,結合生產實際經驗來構建響應式的和適應移動端的應用程式。SPFx同時支援SharePoint本地和Online環境。


SPFx的核心功能包括如下:

  • 沒有iFrame,在瀏覽器當前使用者和連線的上下文執行。
  • 控制元件在正常頁面的DOM中被渲染。
  • 控制元件原本就是響應式和可訪問的。
  • 使開發者可以訪問生命週期,包括但不限於渲染載入、序列化、反序列化和配置變更。
  • 框架無關,可以使用任何你喜歡的瀏覽器框架,比如React、Handlebars、Knockout、Angular等。
  • 工具組基於公共開源客戶端開發工具,比如npm、TypeScript、Yeoman、webpack和gulp等。
  • 效能可靠
  • 終端使用者可以在所有的網站(包括自服務網站、個人網站、組網站)使用經過租戶管理員批准的SPFx客戶端解決方案。
  • 解決方案可以部署在傳統的Web部件、釋出頁面和現代頁面。

執行時模型在指令碼編輯器Web部件做了改進。包含了強健的客戶端API,一個Http客戶端物件來處理SharePoint和Office 365的驗證,上下文相關的資訊,簡單的屬性定義,配置等。

如果你在Visual Studio中使用C#或者是JavaScript,你需要學習一些客戶端JavaScript的開發知識。你的大部分技術知識是可以直接拿來用的。你將會視你的需求使用REST服務或者JSOM物件模型。資料模型沒有任何變化。如果你是一個C#開發者,TypeScript是轉變到JavaScript的一個很好的途徑。IDE的選擇取決於你。許多開發者喜歡使用跨平臺的IDE,Visual Studio Code,同時,Visual Studio也有了一個用於新開發環境的外掛。許多開發者也會使用像Sublime和ATOM這樣的產品。使用你最擅長的。


為什麼用SPFx?

SharePoint在2001年開始,以本地產品的形式被推出。隨著時間的推移,一個龐大的開發者社群以多種方式延伸併成型。絕大多數情況下,開發者社群沿用了SharePoint產品開發團隊使用的模式和實踐,包括Web部件,SharePoint功能XML等。並且許多功能是應用C#開發的,被編譯成DLL,部署到伺服器上。

這種解決方案在單一的企業環境裡執行得很好,但是並不適用於多租戶並行環境的雲。因此,我們引入了兩個可供選擇的模型:客戶端JavaScript注入和SharePoint Add-ins。他們有各自的優缺點。

JavaScript注入

指令碼編輯器是SharePoint Online中最受歡迎的Web部件之一。你可以通過指令碼編輯器貼上JavaScript程式碼到裡面,讓它在頁面渲染的時候執行。它非常簡單和基礎,卻很有效。它執行在跟頁面一樣的瀏覽器上下文和DOM中,因此能夠跟頁面上的其他控制元件進行互動。它也具有相當的效能,並且易於使用。

然而,這種實現方式還有一些不足。首先,儘管你的解決方案可以打包成控制元件讓終端使用者很容易的拖到頁面上,你不能輕鬆地提供配置選項。然後,終端使用者可以修改頁面和指令碼,這會破壞Web部件。另一個很大的問題是指令碼編輯器Web部件並沒有被標識為“Safe For Scripting(指令碼安全的)”。大部分自服務網站集(我的網站、工作組網站、組網站)都啟用了一個叫做“NoScript(無指令碼)”的功能。嚴格地說,它移除了SharePoint中的新增/定製頁面(Add/Customize Page)(ACP)許可權。這意味著指令碼編輯器Web部件在這些網站上將會被阻止。

SharePoint Add-in model

目前執行在無指令碼網站的解決方案是add-in/應用部件模型。該實施建立了一個iFrame,實際的內容在iFrame裡駐留和執行。優點是易於資訊工作者信任和部署,因為它對於系統來說是外部的,沒有許可權訪問當前的DOM/連線。終端使用者可以在無指令碼網站安裝add-ins。

該方案也有一些缺點。首先,它們在iFrame中執行。iFrame比指令碼編輯器Web部件要慢,因為它需要向另一個頁面發起一個新的請求,那個頁面還要通過認證和授權來使它自身能夠被呼叫去獲取SharePoint資料,載入各種JavaScript類庫等。比如一個指令碼編輯器可能需要100毫秒去載入和渲染但是一個應用部件可能需要2秒或更多的時間。然後,iFrame邊界使得建立響應式佈局、繼承CSS和主題資訊變得更加困難。iFrames有很強的安全性,可能會對你(你的頁面不能被頁面上的其他控制元件訪問)和終端使用者(控制元件沒有許可權訪問他們Office 365的連結)有益。

SharePoint Framework

從歷史觀點上說,我們通過把完全信任的C#程式集安裝到雲伺服器來建立Web部件。然而,當前大多數的開發模型包含了在瀏覽器端執行的JavaScript,通過REST API呼叫SharePoint和Office 365後臺的工作負載。C#程式集在這裡就無能為力了,我們需要一個新的開發模型。SharePoint Framework就是SharePoint開發中新的演化。


其他的關於SPFx的license、相關的資源等資訊請訪問原文連結。

相關文章