SharePoint Framework 概述

  1. 云栖社区>
  2. 博客>
  3. 正文

SharePoint Framework 概述

justinliu927 2016-10-06 11:27:50 浏览587
展开阅读全文
博客地址: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、相关的资源等信息请访问原文链接。

网友评论

登录后评论
0/500
评论
justinliu927
+ 关注