2015年1月4日,星期日

为Office 365开发–关于使用自定义母版页和Web模板等的想法

随着越来越多的组织选择在Office 365上部署SharePoint工作负载,它’看到双色球推荐一注更改了对开发人员应如何实施自定义的指导,这很有趣。如果你’密切关注之后,您可能会意识到最近几个月开始出现以下消息:

  • 避免使用自定义母版页
  • 避免使用网页模板
  • 避免在WSP(甚至是沙盒WSP)中使用声明性XML(即功能XML)–并记住,我们已经不应该在这里使用服务器端代码!)

这些消息主要与Office 365 / SharePoint Online空间相关 –但可以说也与本地SharePoint相关。在撰写本文时(2014年圣诞节),这些消息不是’尚未真正在MSDN上发布,但很快将在双色球推荐一注 Virtual Academy培训中发布。在这种想法背后,我非常尊重双色球推荐一注的员工。一世’ve与Vesa Juvonen,Steve Walker,Bert Jansen等就这些主题进行了很好的对话,这些家伙最终不得不与稍有对立的部队作战-“使Office 365成为良好的开发平台,而又不会使服务过于困难/昂贵”将是一个总结。希望这不会’不能让我从他们的圣诞贺卡清单上划掉(!),但是在这篇文章中,我’ll explain why I’我不确定在所有情况下我都同意该指导。

毕竟,这些都是大变化!!没有自定义母版页?没有网页模板?真?? Web模板是不久前解决世界饥饿问题的答案– after all, if you’已经创建了数百/数千个团队或项目站点,并且它们都应该在开箱即用的团队站点之上都具有一些工具/小部件,Web模板是双色球推荐一注提供的SharePoint方式中的工具!长期以来,自定义母版页一直是在SharePoint中实施合理级别的品牌塑造的方式– and that’对许多组织来说很重要。那么,该指导的背后是什么?您需要遵循吗? 对于我们的项目,我’我认为我们应该在比较基于协作/团队站点的内容时遵循它,但不一定要针对更注重通信的高品牌发布内部网。 因此,总结一下这个决策过程:

自定义母版页和Web模板-协作与发布-小型

I’稍后再解释我的想法,但首先让’可以理解双色球推荐一注为什么要提供此指南。

使用自定义母版页/ Web模板意味着您可能不会*自动*获得新的Office 365功能

众所周知,Office 365是“evergreen” platform – it is 经常 更新了针对最终用户的新功能(“ripples, not waves”方法)。要推出这些更新,双色球推荐一注有时需要更新现成的网站模板和母版页。例如:

  • 添加到SharePoint Online团队网站的新功能(例如,使用的新列表或设置)= 双色球推荐一注更新了团队网站模板(STS#0)
  • 通过新的页面控件将新功能添加到SharePoint Online = 双色球推荐一注更新了OOTB主页

当然如果你’重新使用自定义Web模板和母版页,您赢了’不会收到这些变化。  That’很痛苦,因为在很多情况下,您最终都希望得到这些东西–最终用户可能会真正从中受益一些高价值的功能(也许您正在考虑为其构建自定义!)。确实,你’re paying for this “service”在您的Office 365许可中;没有获得全部利益似乎很可耻。随着时间的流逝,’同样可以说,自定义母版页将与OOTB母版页越来越不同步,如双色球推荐一注培训中的以下图表所示:

自定义母版页与OOTB

当然,你能做的是 手动地 例如,将所有母版更新复制到您的自定义母版上–但这每次都要付出努力。某种程度的分析,代码更改,测试,在多个环境中的部署等–每个双色球推荐一注更新都需要所有这些任务。 双色球推荐一注将其称为“customization tax”如果确实在Office 365中使用自定义Web模板/母版页,则必须支付– and I think that’一个很好的描述。

反面–控制更新

因此,如果我们决定使用自定义Web模板或母版页,则需要付出额外的努力。但另一方面,它可以让您更好地控制何时以及如何将Office 365更新应用于您的环境,这可能会很有吸引力。当然,如果您在Office 365全球Intranet上有50,000个用户,并且双色球推荐一注更新有一天会中断主页(例如“breaking”发生了变化),’很多人打电话给服务台,生意非常不愉快!那’这可能是最坏的情况,’可以肯定地说,微软已经围绕更新改进了沟通–但甚至没有那么戏剧性的场景,例如变化’t 打破 除了 更改Intranet体验需要妥善管理。与团队/项目站点相比,发布Intranet往往具有更多“designed”用户体验,自定义品牌/外观和可能进行的更多自定义。这意味着双色球推荐一注更新引起问题的可能性更大,也许与较小的自定义存在某种冲突– usually you’d希望有机会 测试 these 事情s together before applying in production.

如果没有其他问题,也许使用自定义Web模板/母版页是 一层 防止发布Intranet的不受控制的更新。赢了’不能涵盖所有情况(取决于更新的类型),但肯定可以涵盖许多情况。 但是,我强烈认为,协作场景(例如团队站点和项目站点)通常不应使用自定义Web模板/母版页。 那里’在这些区域中进行大量的品牌化/外观定制的好处较少(因此不需要自定义母版页),而且我认为您真的希望从双色球推荐一注获得任何更新。–它可能是您的业务用户将欣赏的有价值的新功能。此外,由于您经常 许多 协作网站集(但只有一个发布Intranet网站集),从双色球推荐一注手动将任何更新复制到这些区域的想法也更加复杂。因此,我的起始位置是一个自定义Web模板/母版页,用于发布方案,但不用于协作方案–显然,每个实现都可能需要考虑其他变量,但是’这是我的默认思维。

其他保护层

As a slight aside, other 事情s you could 做 around 双色球推荐一注 updates to Office 365 include:

  • 密切监视有关更新的双色球推荐一注通信– particularly:
  • 为测试目的运行其他Office 365租约“First Release” mode enabled
  • 如果可能,请注册NDA Preview程序

到底有多少负担“customization tax” anyway??

对于许多推出Office 365的组织(尤其是大型企业),我可以’帮忙,但认为这“customization tax”通常在许多方面都是海洋中的一滴水。与我合作的大多数客户已经有一个(或多个)团队来处理其他推出或定制任务,他们知道,要启动这些功能并发送几个电子邮件以充分利用这些资源,不仅需要花很多时间。该平台。在Intranet的整体运行中,偶尔需要开发人员进行一些更新非常好。

所有这些因素使我想到了使用不同的方法进行协作与发布Intranet方案。

自定义Web模板和母版页的替代方法

但是让’s say you 不要’不想使用自定义Web模板或母版页或两者都使用)-可能是因为您’重做团队网站,或其他原因。 您如何获得相同的效果(双色球推荐一注会建议些什么)?

如果你需要…

“Classic” approach

替代方法

应用自定义品牌/外观
  • 自定义母版页
  • 使用合成的外观/主题/备用CSS文件进行外观
  • JavaScript注入以添加自定义页面组件/控件
有一个模板可以从中创建许多站点
  • 自定义网页模板
  • 网站基于OOTB网站类型(例如团队网站)和。
  • ..采用 远程配置代码 在网站创建后配置内容类型,列表/库等。这里的两个关键方法是:

显然,在实现过程中需要对替代方法进行一些思考,并且通常会付出额外的努力–但是您应该发现它们至少对于非发布方案(例如团队/协作网站)效果良好,因此在某种程度上符合我对这些实现进行不同对待的想法。但是,您可能会发现,对于高度定制的Intranet不使用自定义母版页还是很困难的,尤其是在涉及诸如响应式设计等方面时。在模板方面,微软的指导是使用 远程码 将定制应用于开箱即用网站的方法。这可以追溯到我打开的项目符号要点列表中的另一点’t discussed yet:

避免使用声明式XML进行配置(改用基于命令式/基于代码的方法)

因此,是的,尽管我们许多人在过去几年中一直使用功能XML进行配置,但双色球推荐一注现在希望我们不要在Office 365中使用此方法,即使该方法仍受100%支持。当然是“XML与用于供应的代码”争论已经有很多年了,但是微软现在在代码方面大打折扣。–在SharePoint Online中,这意味着远程代码(CSOM或JSOM)。它’停下来思考一下我们的事情类型很有趣’d通常在这里使用XML:

  • 设置字段和内容类型
  • 供应列表和库
  • 设置文件(“site infrastructure”文件,例如母版页/页面布局/ CSS / JavaScript /图像等,或默认内容,例如页面或文档)
  • 设置Web部件
  • 声明模板–列出模板和Web模板(以及之前的网站定义)
  • 添加CustomAction(例如,链接JavaScript文件或添加功能区自定义项)
  • 自定义字段控件
  • 委托控件
  • 声明事件接收者
  • 功能接收器

其中只有几个(例如功能接收器,自定义字段控件,委托控件)可以’不能在沙箱中使用(因此也可以在SharePoint Online中使用),但是您可以通过其他方式实现同​​一目的。 其余的可以,但是微软开始说我们应该尽可能使用远程代码代替XML。原因是在SharePoint内部,该功能变得依赖于某个地方的XML文件,而不是单纯地位于内部“provisioned”内容数据库中的项目–这会使某些系统升级更加复杂。 虽然这是一个有趣的SharePoint工程“thing”, it’很难将其视为我们的问题,而不是Office 365工程团队’s – after all, these upgrades are mainly 事情s that 双色球推荐一注 will undertake as part of running SharePoint Online. 的 “内容数据库升级”例如,将Office 365升级为使用SharePoint 2015(或任何其他版本)的一部分就是一个示例。 

作为带领20名开发人员随时处理许多SharePoint / Office 365任务的小组的人,我目前对团队完全保留所有方案转向基于命令式/基于代码的置备有些保留。一世’过去曾在Steve / Vesa等人提到过–本着公开讨论的精神,这里’是我对“don’使用声明性XML”对话中的消息:

我的一些快速想法是:

  • 切换到命令式配置的某些方面非常不方便-我的团队(和SharePoint开发人员通常)在声明式配置方面非常高效(约7年的经验;),并且Internet上的许多资源都对此非常关注。
  • 声明性/ XML方法已由双色球推荐一注推销了7年,即使现在Office 365仍支持100%。
  • 我完全明白,如果所有客户都使用命令式配置而不是声明式,则某些事情/升级对于Office 365工程而言将更为简单。但坦率地说,我不确定我是否也加入了这个计划!我知道在某些地方,它作为初始实现者可能与我非常相关(例如,初始部署可以声明性地完成,但是更改/更新需要代码),但是即使如此,我们还是经常*仍然*更喜欢声明性进行初始配置!
  • 强制性配置显然不能轻松涵盖某些模板化方案-列表模板,站点模板等。当然,我可以实现一些功能类似的远程配置解决方案,即使使用OfficeDev示例,’d表示,这比声明式方法要花更多的精力-而且,有时没有简单的方法可以使内容出现在最终用户UI的预期位置(尤其是列表模板)。真是差距很大。
  • 提供生产级的弹性“remote code hosting”对于某些客户端(例如,对此不满意的客户端),解决方案可能会很困难。 

看看这个区域是如何及时发挥作用将很有趣。这些显然只是我的意见,’的确,使用代码而不是XML可以带来好处(例如更好的调试和日志记录)。但是,不再同时拥有这两种选择似乎是可耻的。最终,如果您将此子决策现在仅作为发布Intranet等的考虑因素,’很高兴想到面向协作的站点确实应该使用带有远程供应代码的OOTB站点类型(换句话说,’ve已经决定在此处使用代码)。但是我’我当然还不愿意全面放弃声明式方法。

概要

那里’新指南中有很多要考虑的内容,还有什么’在一种情况下的权利可能在另一种情况下的权利不正确。它’您可以考虑各种因素(以及需要实现的目标),但是像往常一样,尽可能了解地形有助于您做出最佳决策。我的想法是考虑以不同的方式发布Intranet和协作网站–但希望这篇文章至少可以帮助您详细考虑该怎么做!

23条评论:

未知说过...

关于母版页和Web模板的自定义的很棒的想法。
我研究了自定义母版页,发现可能值得考虑的事情可能会在将来更新双色球推荐一注 SharePoint母版页和对用户界面的更改。我在博客文章中对此进行了记录 案例研究如何在Office 365和内部部署中使用相同的母版页
亲切的问候
斯特凡

未知说过...

有趣的阅​​读。作为使用本地SharePoint 2010安装的人,我'm not sure I'我曾经想过寻找那种"ripple"您在此处描述的v4.master中的更改。母版页在Office 365中多久更改一次?

夸特说过...

我总是说,页面离最终用户的日常流程越近,您越想坚持使用现成的SharePoint界面。哪个符合你。

所以我同意=>公司内部网=>品牌。团队站点,项目站点等=>没有商标(仅使用主题等较小的样式)

布鲁斯说过...

不错的写作(像往常一样)。考虑到您对这种方法的投入,我很高兴您不愿放弃声明式IA的提供。

对于多年来一直使用Excel定义IA并使用它来提供PowerShell部署脚本的那些人来说,我们轻而易举(或者更确切地说,是事先无意中选择了获胜方)。

我使用Intranet =品牌vs团队站点=时遇到的困难不是,根据我的经验,客户对于两者都希望使用相同的UX。试图向他们出售丑陋的团队网站体验绝非易事...

匿名 said...

"I completely get that if all customers used imperative provisioning rather than declarative, certain 事情s/upgrades would be simpler for Office 365 engineering."

通知我们'我来了一个完整的圈子。微软是否正确理解了声明式背后的概念?它'从顾问的角度来看,让我们感到沮丧是一件非常令人沮丧的事情。'有人告诉他们,因此没有任何方向的明确指导,所有人都被扔到公共汽车底下。它'令人沮丧的是,其他CMS解决方案为品牌化方法提供了清晰的途径,并具有选择加入的版本控制功能。也许这是MS希望我们转售的指导:去其他地方。

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

@Unknown(第一个),

It'一个好问题(关于在Office 365中多久更新一次母版页)-我不知道'这个没有任何数字,所以它'很难确切说出(除非专门监视此情况的人可以听到?)。但是,从去年对顶部导航栏(后来又引入了应用启动器)的更改到对SharePoint网站的移动视图的更改,去年已经推出了一些UX更改。我想这里的另一个有趣之处是,展望未来,我'd建议即使微软也不能'今天不告诉你他们有多少改变'在接下来的12个月中,我们会说-这将取决于所引入的新功能的种类,而现在,这更多地是通过响应分析而不是长期计划来实现的。

干杯,

COB。

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

@布鲁斯,

是的,有趣的想法,我们've definitely used similar approaches in places. However, I feel they 不要'始终适合,因为它们严重依赖I.T.创建的网站使用"magic script"-在某些情况下绝对可以,但并非总是如此(例如自助式网站配置)。

但是正如您所说,如果在某些时候离开声明性配置成为强制性/关键性,那么这种方法确实是制胜的一面(一种形式):

在您的其他评论中,您是否发现客户要求对团队站点进行大量的UX自定义?即比主题/组合外观所能实现的还要多?

干杯,

COB。

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

@未知(第二个),

是的,我一定会听到您的声音,当双色球推荐一注旅行的方向发生变化时,这可能会令人沮丧-它经常也会损害我从事的工作。但从积极的方面来说,我认为SharePoint / Office 365工程团队现在比以前更敏感于这些更改。另外,作为一个可能在幕后看到更多东西的人,我的确看到了双色球推荐一注经常面临的挑战-改进事物(但由于过程中需要进行更改而使人烦恼),或牺牲由于破坏。当然,有时候"new stuff" is simple and 做esn'带来改变的需要'已经存在,但是有了十年前的平台,很明显,'并非总是如此。

整!

COB。

未知说过...

克里斯读得很好
我刚刚开始一个新项目,我们将在其中设计和实施向O365的迁移,并且需要与品牌组件一起讨论迁移策略。本文对我的决策过程有所帮助。干杯。几个月后在伦敦见面。

奈杰尔说过...

克里斯你好
新年快乐 !
我认为这比您亲密的要广。如果您拥有SP2010服务器场,并且希望迁移到SP2013(尚不可以选择联机-英国尚无MS数据中心!)。一个人如何构建一个SP2013服务器场,以便当该到在线迁移到SharePoint时,我们如何最大程度地减少工作量和中断。现在,在构建SP2013服务器场时应考虑您所描述的内容。希望您可以将这些技术用于本地托管的应用程序,而不是Azure。如果是这样,那么我们将在某种程度上减少"moving to the cloud" 在 a later date.

奈杰尔

亚当·托斯说过...

使用自定义母版页不是't going to insulate/protect you from 破 changes from 双色球推荐一注.

您的自定义母版页将引用控件(如功能区),双色球推荐一注可以随时更改其基础DLL,从而可能更改从这些控件发出的标记。如果您有针对特定页面DOM元素的自定义JavaScript或CSS,则标记更改可能会使这些自定义失败。

It'对于客户来说,这是一个非常艰难的处境。我与aren合作的许多公司't willing to wait indefinitely for 双色球推荐一注 to finally provide a responsive team site master page and create it themselves (and sign up for the 定制税 in the process).

仍然基于ASP.NET 2.0的技术的所有症状,从来没有很好地分离逻辑/ UI。

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

@奈杰尔

是的,这很不错-我'd虽然说,这也许可以说明"cloud-friendly" development. For a while now, 许多 of the on-premises projects my team has worked on have used 云友好 approaches precisely to minimise any re-work if/when a move to Office 365 happens. This means developing exclusively using client-side techniques and the app model/remote code model, and avoiding all the 事情s which cannot be used in SharePoint Online (e.g. server-side SharePoint code, timer jobs, files deployed to the _LAYOUTS directory and so on). More details on this stuff 在 演示平台:现代SharePoint开发-现成代码的技术

最终,这"roadmap to the cloud"我们*总是*与我们的客户进行讨论,即使他们是本地的,也不是'特别是在他们的雷达上。

干杯!

COB。

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

@亚当,

好吧,我绝对同意使用自定义母版't protect you from *all* 破 changes from 双色球推荐一注, and that some updates will come from web control DLLs for example. This is what I was trying to say with:

"如果没有其他问题,也许使用自定义Web模板/母版页是 one layer 防止发布Intranet的不受控制的更新。赢了’不能涵盖所有情况(取决于更新的类型),但肯定可以涵盖许多情况。"

但是,我仍然认为自定义母版页将为您提供一些东西-否则双色球推荐一注不会'不管人们是否使用过!他们说的事实"you shouldn'如果要所有更新,请使用自定义母版页 "我很清楚,将以这种方式部署一些更改。在拥有50,​​000个用户的Intranet主页的情况下-坦率地说,值得您获得每一个保护层吗?

干杯,

COB。

杰里米·塔克(Jeremy Thake)说过...

一如既往,克里斯,感谢您的出色撰写。

Vesa Juvonen and Steve Walker recently did a live event on this topic which is now available on-demand (http://www.microsoftvirtualacademy.com/training-courses/transform-sharepoint-customizations-to-sharepoint-app-model )

I've also 不要e some podcasts with Steve and Vesa on this too which can be found here http://blogs.office.com/2014/10/02/office-365-developer-podcast-episode-018-steve-walker-sharepoint-ux-developer-guidance/ and more shows here http://dev.office.com/podcasts .

We also very recently updated the Solution Pack for SharePoint Online with more guidance on this topic http://www.microsoft.com/en-us/download/details.aspx?id=42030

我将继续监视有关此问题的评论,因为人们对此非常关注,因为这对恢复工程非常有用。

匿名 said...

最好有双色球推荐一注的指导,因为我经常告诉客户,如果可能的话,他们应该尽量坚持使用。

但是,远程配置的一大领域是工具问题。 Visual Studio中对声明性字段,内容类型等的工具支持改进了每个版本,并且切换回完全不使用工具的方法(原始代码),对生产率产生了很大的影响。

(如本文所述,另一个主要领域是现有技能,但MS可以'不能真正解决这个问题。)

如果MS希望这样做,他们确实必须在为远程配置的生成代码(部分类)的工具支持上投入大量资金。 (类似于ASP.NET或Entity Framework中提供的功能)。

借助一些不错的工具,包括对模块化的支持和轻松的应用/回滚,远程调配解决方案将与现有的声明式声明一样容易(具有诸如调试之类的改进优点)。

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

@杰里米

Thanks for adding the links. 那里'在这里显然有很多思考/讨论的地方,因此感谢您为成为双色球推荐一注所做的努力'像往常一样的眼睛和耳朵:)

干杯,

COB。

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

@Sly Gryphon,

我认为所有这些观点都必须100%同意。不过,要等到达到理想状态可能还需要一段时间-尤其是在回滚之类的方面(考虑到基本的SharePoint体系结构,这永远都不简单)。

好的评论,欢呼!

COB。

布鲁斯说过...

@Chris, the biggest 事情 that clients ask for that can't be achieved through composed looks/themes is a fully responsive design (commonly 不要e by integrating bootstrap in the master page and page layouts). Jeremy has said that MS is slowly moving towards making the OOTB master more responsive (some components like the suite header already are), but they aren't there yet.

匿名 said...

@Bruce 那里 are patterns and practises expounded by Steve Walker and Vesa Juvonen of 双色球推荐一注 here :- http://www.microsoftvirtualacademy.com/training-courses/transform-sharepoint-customizations-to-sharepoint-app-model

允许您将响应式用户界面的引导程序注入母版页。因此,您现在就可以这样做。

未知说过...

我们最近还更新了有关SharePoint Online品牌和自定义的指南。

规划SharePoint Online的自定义项,解决方案和应用

布鲁斯说过...

@奈杰尔-我'm知道该培训(我很早起床现场参加了会议)。我会质疑"injecting"运行时的boostrap标记。即使您能够以这种方式使其工作,它也将变得非常脆弱-对OOTB母版页进行的最小更改可能会破坏它,然后您'回到您的起点。

理查德·沃尔什说过...

阅读此出色的总结及其后的评论,尤其是围绕不使用声明性XML设置技术的新方向,我可以'帮不上忙,但是这又是另一个"解决非问题", a la Furuknap.

我在SharePoint领域拥有近10年的经验,对于双色球推荐一注在所有这些方面的发展方向,我真的开始感到绝望。我知道他们这样做的原因(无论如何,在许多情况下),但是要求SP开发人员放弃他们多年来已完善的技能的方式很难采用。作为一个刚从大学毕业的年轻开发者,我'我不确定在此阶段是否有重新技能的愿望,尤其是当基于刻薄经验的玩世不恭的态度告诉我,微软将来可能会在所有这些方面再次改变方向。

奥马尔说过...

It'MS会在同一版本中引入Design Manager并阻止品牌推广,这很有趣。