2013年5月29日,星期三

SP2013 主机网站 apps: provisioning files (e.g. master pages) to the 主机网站

在2013初夏,’在SharePoint开发领域度过了一段奇怪的时光。信息是沙盒解决方案是“deprecated”在SharePoint 2013中(无论您选择哪种方式进行解释),并且我们应尽可能构建应用程序–但是,应用程序目前无法完成沙盒解决方案可以执行的许多操作。当然,应用程序与沙盒解决方案之间的主要区别在于,当您在应用程序中配置字段/内容类型/文件等时,它们是在应用程序网络中创建的– not the “host web”。对于许多要求,这“isolated space” idea works fine. However, when you really want your artifacts to exist in the day-to-day areas of SharePoint that users go to (i.e. the team/project/My sites that become known as 主机网站s in the app world) then you need a different approach.

如果你’不再舒适使用沙箱,那我们该怎么办?好吧,要考虑的一种选择是应用有时可以“provision to the 主机网站”。本文着眼于这个想法,但首先提醒我们整个系列中的情况:

  1. SharePoint 2013应用–架构,功能和UX注意事项
  2. 入门–在SharePoint应用程序中创建列表,内容类型,字段等(配置)
  3. 在应用程序网络中使用数据以及为什么要这样做
  4. Access end-user data (in the 主机网站) from a SharePoint 2013 app
  5. 将SharePoint 2013应用推广到企业-租户范围和PowerShell安装
  6. Azure是新的SharePoint‘_layouts’ directory
  7. “Host web apps” – provisioning files (e.g. master pages) to the 主机网站 [本文]
  8. “Host web apps” –设置字段和内容类型
  9. 将SP2013提供程序托管的应用程序/远程事件接收器部署到Azure网站(用于Office 365应用程序)
  10. 在SharePoint应用程序中使用Web部件
Anyway, apps can provision to the 主机网站 IF:

  • 应用程序请求(并被授予)“Full Control” permission of the 主机网站
  • CSOM代码用于配置,而不是标准功能XML

突然之间,应用程序现在可以用作部署的工具“regular”SharePoint功能–也许是典型协作解决方案中使用的组件。本文中的代码/解决方案摘自“深入研究SharePoint托管的应用程序”在SharePoint Evolutions Conference上的演讲,这篇文章是关于此类的一系列简短文章的第一篇“host web apps”(在我关于SP2013应用的更广泛的系列中)。但首先..

你应该这样做吗? Deciding between 主机网站 apps/sandbox/farm..

我认为这种方法有地方–特别是如果您对沙盒解决方案的预期寿命抱有幻想,或者有人坚持使用应用程序模型。但是,我的感觉是我们正在有效利用这里的漏洞。一世’确保Microsoft并没有特别打算以这种方式使用应用程序(基于困难的基于CSOM的部署模型证明了这一点),但是,可能由于其他原因,它们具有稳健的机制,因此无法’t主动阻止。我?好吧,我个人认为,如果客户要求引导您转向托管网络,那么应用程序就不是’t the right vehicle – if you’再以云端为重点,那么我认为您应该使用围绕沙盒为中心的设计。尽管"deprecated”标签,我认为Microsoft必须先扩展应用程序模型,然后才能真正删除此选项。换句话说,我认为我们应该理解我们正处于过渡时期,新的开发方法将可用– but I won’现在就为工作使用最好的工具感到很遗憾。

我应该补充一点,这可能不适用于产品开发–我目前不必担心的区域。我的朋友 道格·韦尔 is building an app based around the 主机网站, and has dug far deeper into this than me. We’ve之前在我们的博客文章中讨论过此主题–您可以在 SharePoint应用程序:使用应用程序网站以及为什么要这样做。您’ll see that I’有效地软化了我的位置 在这篇文章中。

How to: provision a master page (or any file) to the 主机网站

在这个例子中,我’m选择提供母版页–但是该方法也适用于其他文件类型。可以说,最好的方法是至少在最初将文件提供给应用程序网络。之所以有效,是因为稍后’我需要从某个地方获取文件内容,而不是直接在JavaScript变量中声明整个文件内容(不太实用)。因此,我们将文件添加到我们的应用程序中,并使用Module元素将其置备到应用程序网络中。我发现在此阶段配置.txt扩展名是最好的(稍后再介绍):

最初配置到应用程序网络

编码

然后我们需要大量的CSOM代码–在我的情况下,特别是JSOM。一世’m使用SharePoint托管的应用程序,其中代码在应用程序默认页面的页面加载时执行。在代码中,我们必须掌握一些技巧–首先,我们向应用程序网络中的.txt文件发出jQuery GET请求,以获取内容。 N.B.这就是我们首先为其提供.txt扩展名的原因–对于某些文件类型(例如.master,.aspx),您可能会发现文件内容与预期不符。之所以会发生这种情况,是因为SharePoint无法正确执行/解析该页面,即由于您有效地浏览了母版页/页面布局/其他内容而发生了运行时错误 。如果您只是请求一个.txt文件,这种不希望的行为就会消失。

Then we use JSOM to open a connection to the 主机网站. We do this by passing a relative URL to the 主机网站 到SP.ClientContext构造函数,而不是请求SP.ClientContext.get_current(),这将为我们提供运行页面的应用程序网络中的上下文。

Our JSOM code then uploads to the 主机网站 (via a method which can be re-used to provision any file to any path in the 主机网站), and just for good luck we go ahead and set the master on the 主机网站. 编码 below has no external dependencies, and should work fine if you paste it into your app:

** N.B.我较新的代码示例未在RSS阅读器中显示- 点击这里查看全文 **

运行应用

构建我们的应用并将其添加到网站后,添加人员必须接受“完全控制”权限请求:

  完全控制应用程序权限要求

并且,由于这里的模型是在页面加载时执行我们的JSOM代码,因此,当用户导航到应用程序时,我们的母版页确实已置备。我的示例代码展示了一些简单的UI来确认这一点:

文件配置成功UI

结果

Now when we go back to the 主机网站, we see that our master page has indeed been provisioned to the Master Page Gallery:

已配置母版页

..并且由于我们将其设置为默认母版页,因此该母版页中的任何品牌更改(例如本例中的红色条)都已应用到该网站:

母版页已更改

因此,如果您确实想避免使用沙盒解决方案或主动使用应用程序,那么可以看到这些CSOM技术可能会有用。在以后的文章中,我将进一步介绍其他常见场景的代码。

下载代码

You can download the full Visual Studio project with the code I used for these two articles (on 主机网站 apps) from here – 下载代码.

10条评论:

马格努斯·汉森说过...

克里斯,你好!
如何将母版页和其他工件置备到SharePoint的绝佳示例。我敢肯定,将会有很大的帮助。

谢谢
// M

帕斯卡·范弗伦德宁说过...

好文章!

匿名 said...

在完美的时间,这是一篇很棒的文章。我被要求做完全相同的事情。无论如何,您可以将代码上传到网站吗?作为2013 App Model的新手,请遵循该代码。
提前致谢,
安德鲁

未知说过...

克里斯,你好!
我不'不想杀死Messenger,但这种部署方法感觉像是倒退了一步,而且容易出错。
尽管在技术上无疑可以解决您的问题,但在我看来,这就像是ALM的噩梦。
如果必须升级母版怎么办?重新部署应用程序,然后导航到所有SiteCollections以重新设置?
I am really hoping that MSFT gets going quickly to provide a real alternative for sandboxed and farm solutions. Otherwise I fear that in 3 years from now we talk about the App model beeing 不推荐使用 too ;)
干杯
马蒂亚斯

克里斯·奥'Brien说过...

@匿名,

I'现在,我们已经上传了代码,并在文章末尾添加了链接。

HTH,

克里斯。

克里斯·奥'Brien说过...

@Matthias,

是的,我不'完全不同意。 ALM确实是一个大问题"site infrastructure"文件(例如母版页)(不过,您可以按照以下内容在外部引用它们: Azure是新的'layouts' directory)。但是,我可以相信,有些人会发现这种文件配置技术在某些应用场景中很有用-也许对其他类型的文件(例如Office文档)进行配置?

总的来说,我也希望这种开发模式不会变得普遍。在里面"Should you do this?" section, I mention that I feel the approach is something of a loophole. Despite the 不推荐使用 tag, my personal view is that (here in 六月 2013) I'd prefer sandbox development when provisioning to the 主机网站 is required - it'只是我会尽可能避免使用代码。

有效地我'我在写这些帖子"response to demand" :) I'我对以下问题有一些疑问 "if you *really* didn'不想进行沙盒开发,您可以让一个应用执行X吗?". It'在工具箱中拥有一个好技巧。但是向前,我'我还期望Microsoft在应用程序模型和沙盒解决方案之间进行更改。

感谢您的明智的评论,良好的讨论:)

干杯,

C。

未知说过...

很高兴您也这样看(我没有'真的怀疑它;))我读了你关于"Should I do this?" of course!

不幸的是,AppModel仍然不适合替换服务器场甚至沙盒解决方案,但是我想微软会迅速发展它。

我认为,即使许多开发人员担心并讨厌普通解决方案中的所有XML,使用标准的声明性方法来完成常见的事情(例如,创建列和内容类型,如您在本系列的下一篇文章中编写的内容),而不使用JSOM。

因此,至少我希望在App模型中看到类似的东西。但是也许我一个人怀着那个愿望;)

顺便说一句,看看Richard diZerega的两个非常有趣的帖子,它们也试图解决基于SPO / Office365的解决方案的问题:

通过以下方式进行SharePoint 2013 App部署"App Stapling"

使用Apps for SharePoint 2013进行自助网站配置

干杯,并保持良好的职位!

马蒂亚斯
@mattein

苏珊·C。说过...

我试图下载您的VS项目,但是它说文件已被删除,重命名或暂时不可用。你能检查一下,看看是否有'有什么办法可以再次使它正常工作?谢谢!

克里斯·奥'Brien说过...

@苏珊C,

抱歉,链接现已修复。

谢谢!

克里斯。

匿名 said...

克里斯,很棒的文章。 App Model的新手,这对我来说是一个伟大的垫脚石。