将SharePoint提升为Web应用开发平台

这次TechEd我和老侯讲的Session,在MVP Community Cabana,和其他几个同等类型的session相比起来听众不多

把大致内容和demo的截图总结一下,算个记录,也给没机会去TechEd的留个东西,另外给我们的一些组件做个广告

言归正传,这个Session的表面上的主要内容是应用WSS构建数据跟踪(Data Tracking)类型的协作应用平台,实际上是通过自定义字段类型来拼装SharePoint应用。首先这个应用平台的两个限定词先解释一下:

1、数据跟踪类型的应用,其实按理说应该是叫数据流类型的。基本上就是以数据流转为主的协作应用,比如场地预订、图书借阅之类的

2、协作型应用,也就是说是由一组人或一些角色来共同完成的应用。比如小组、部门或企业内部的。

微软将应用平台按照类型划分为大概如下几种:Lists(由简单数据表构建的数据存储)、Tracking application(数据跟踪类型)、Mini LOB application(简单的小型业务系统)、LOB(Line of business) application(企业核心业务系统)。按照其应用的数量(横轴)和构建复杂度(纵轴),微软给出了这样一张图:

image

数据列表类型的应用虽然构建简单,但占据了大量的数量(例如联系人、通知、讨论、简单的文档共享灯);企业核心的业务系统虽然构建复杂,但应用的数量相对非常少。

先来看看一个应用的组成部分,以及SharePoint在这些部分中的优缺点:

(1)数据结构定义。SharePoint的列表是一个很好的容器,虽然其存储能力有限,但一般来说足够满足一些日常的应用。而且SharePoint列表也如同数据表一样,内置了多种数据类型,并且包含了一些构建应用基本的“应用字段类型”,例如超链接、选项、查阅项等。

(2)视图。SharePoint内置的列表视图功能比较完善,支持数据列的选择、筛选、排序、最大两级的分组等等。不过SharePoint视图没有权限,难以通过视图控制不同角色的查看。

(3)表单。SharePoint列表创建出来之后,会自动生成3个相应的表单:查看、新建和编辑。但是表单的样式、字段的样式都是固定的,即使通过SPD,能够做出的修改也非常有限,难以适应用户多样的需求。

(4)权限管理。SharePoint在发展到WSSv3之后支持到条目级别的权限。但是不支持字段级别的权限,这对于应用来说比较麻烦,难以控制某些字段哪些人可见、哪些人可以编辑。

(5)业务逻辑。SharePoint列表只是一个容器,应用的逻辑一般都需要开发或配置来完成。好在列表的工具栏、下拉菜单都提供了方便的扩展特性,可以加入一些自定义的操作。事件处理程序、工作流也可以在一定程度上满足对条目在逻辑方便的控制。

WSS作为一个以协作为主要目的平台,经常被用于进行文档管理、知识管理、简单的内容共享的应用(也就是对应Lists类型的应用);而且大多数用户都希望SharePoint能够方便的完成复杂一些的协作型应用(也就是图中第二个层次的应用,也是这次session的主要议题)。然而在使用中,我们会发现SharePoint虽然提供了很多方便的特性,但在某些关键方面难以满足我们的需求,无法通过内置功能的拼装达到我们的目的,需要进行二次开发。而这个session的主要目的,就是通过一些开发好的自定义字段类型组件,来方便、快速地拼装出实际的协同应用平台。

自定义字段类型我就不再过多地介绍了,这是WSSv3新加入的特性,极大地扩展了对列表的开发余地。通过自定义字段类型,可以根本地解决表单多样性的问题、从一定程度上解决字段级权限控制和业务逻辑的辅助。

后面就是通过我们一些已有的自定义字段类型,来完成一些特定的功能,最后给出一个由自定义字段类型拼装完整应用的例子。

先来看几个简单的例子:

1、内容类型图标。内容类型也是WSSv3新加入的一个特性,允许我们在一个列表中放置不同结构、同样目的的内容。一旦在列表中开启了内容类型的控制,就可以创建多种内容类型的条目,但是这些条目在列表视图中很难直观地区分开来(内置的方法只能通过显示“内容类型”这个字段来区分,当然,文档库的文档类型图标是一个例外),于是通过这个自定义字段类型,就可以给不同的内容类型设置不同的图标(在视图和新建菜单中),使得应用看起来更加直观和专业。(目前这个图标还可以控制点击后的行为,比如进入查看页面、编辑页面等)。

image image

2、外部图片。在WSS上做新闻编辑或者图片插入的话非常头疼的就是图片上传和图片插入的分离(如果在MOSS上,还可以用发布功能里的那个插入图片来顶一下)。这个字段就是利用一个高级编辑器(FCKeditor)的二次开发接口,将图片的浏览、上传放到了网站的图片库中(第二张图是在浏览网站的图片库,并且可以将新图片从本地上传到图片库中)。

image image

3、Email地址。这个很简单,就是在单行文本的基础上加了Email格式验证,虽然原理和实现都很简单,不过却很有用。

image

4、设置字段的隐藏和只读。这是一个比较复杂的自定义字段,可以根据条目中某个字段的值、当前用户等内容进行一个复杂的表达式计算,来控制某个字段是否显示,或者是否可编辑。

image

5、密码字段。这个没截图……就是在显示、新建、编辑密码的时候打上马赛克,并且在储存的时候用某个私钥进行加密。新建时候要求输入两次,编辑的时候需要输入原密码以及两次新密码。

之后,通过一个完整的会场预订的应用,展示了如何通过自定义字段类型,来快速地拼装这种协作型的应用:

首先,一个会场预订的功能必然会有一个会场的列表。使用一个自定义列表来创建会场列表,包含了会场的标题、所在区、所在酒店和一些相关信息。

1、在很多地点相关或者类型相关的字段中,我们往往能够希望两个甚至多个下拉列表框能够互动,比如说当选择“北京”后,列出北京的区域;选择天津后,列出天津的区域。这可以通过一个自定义字段类型来完成,相关联的父字段、关联的内容都可以灵活定义:

image image

2、作为相关内容,一个场地肯定会有多条相关内容。这也是在应用构建中非常常见的一种主-子表类型的表关联,通过一个外键进行关联。在SharePoint中,查阅项的作用与此非常类似,可以在子表中设置一个指向主表的查阅项(外键)。然而这种查阅项有时是非常不直观的,只能在子表中看到其条目属于哪个主表,难以看到主表条目中有哪些相关的内容。通过一个“反向查阅项”(或者主-子表字段)类型,就可以实现这一功能。设置可以在主表的编辑页面中,直接新建、修改、删除相关的子表字段:

image

实际上这个相关内容是保存在另一个列表中,有一个指向“场地列表”的查阅项。主表编辑页面中的新建、编辑页面直接使用了子表的新建和编辑页面,只不过做了一些小的修改(在表单打开时自动初始化查阅项指向对应的主表条目)。

3、预订场地通过另外一个列表来实现,可以直接进入这个列表新建列表条目,然而更直接也更友好的方式,就是直接在场地列表中对“心仪”的场地进行预订操作(在列表界面和条目界面都可以进行操作,直接转入场地预订列表的新建页面):

image image

4、场地预订列表中为了标示预订的场地,会设置一个查阅项指向场地列表。但如果出于某种考虑,希望讲场地列表和场地预订列表放在不同的网站上(例如场地列表在资源网站上,由资源管理者统一管理;而场地预订列表在会议网站中),就需要借助另一个自定义字段,跨网站查阅项。这个自定义字段和查阅项的功能基本相同,只是SharePoint内置查阅项只能查阅同一网站中的列表,而这个可以跨网站查阅,并且可以指定一个视图做初次筛选(以免查阅项中出现的内容过多难以选取)。(其实跨网站查阅这一功能在SharePoint查阅项中是提供了的,只不过没有开放到界面上)。它的设置界面:

image

5、所有资源预订类的应用都必然有一个需求,那就是冲突检测。一般的做法是将冲突检测放在事件处理程序中,如果有冲突则抛出异常,不过这不够方便,如果能够在填写场地、时间的时候就能实时地检查是否有冲突,那是最好不过了:

image

这是一个挑战想象力、颠覆传统的自定义字段类型,按照惯常的思维方式,列表的字段一定是作为某一种特定的数据存储之用的;然而,这个“时间冲突检测”的自定义字段类型,不保存任何数据,仅是在新建和编辑页面上出现,提供一个操作。

好了,现在我们可以看到这些场地预订的情况了,日历视图能够让显示更加直观:

image

6、最后,一个预订系统必然要有的一项就是管理员的审批操作。“好,这个地方这段时间就归你了。”/“不行,这个地方要留作它用。”管理员的选择无非就是这两种。当预订较少的时候,管理员可以直接通过SharePoint的审批视图依次查看每个条目进行审批;但一旦条目多起来,偷懒的管理员(懒是世界进步的动力,嗯嗯)希望能够一次性审批多个条目。“要是能像邮箱那样给个多选框,让我选中要批准的,再一点鼠标,就全部搞定该多好。”于是又一个自定义字段登场,它同样只作用于展示层,不保存任何数据:

image

配合这个自定义操作,管理员就可以有更多的时间来……咳咳。

至此,一个完整的会场预订功能就拼装出来了。尽管它有一些简单,但是基本上包含了一个数据流转的协作型应用的所有步骤了。而且在这个应用拼装的过程中,除了最后为真正完成多项审批而编写的10行左右代码,整个过程中几乎没有任何代码操作,完全通过自定义字段类型和其他一些webpart的配置就达到了目的。这极大地方便了管理员的操作,于是IT Pro们就有更多的时间用来聊天灌水了(这不是我,嗯,我不是IT Pro,嘿,说你呢……)。

当然,最后这个应用里有一些小trick,比如如何改变列表条目的下拉菜单、如何改变工具栏菜单。当然,你说可以通过feature来做,但是这个demo中的这些菜单没有一个是通过feature完成的。为什么?因为feature只能挂在某中列表类型或者内容类型上,麻烦……至于是怎么做的,等今后有时间再慢慢介绍。

这些自定义字段类型,我们迟早会发布出来,有些简单的可能就直接free了。请关注公司网站:www.servbus.com,或者直接给我发邮件:duwei@servbus.com。(打到技术blog的广告行为……)

原文地址:https://www.cnblogs.com/erucy/p/2416078.html