《SharePoint Portal Server 2003 深入指南》开发部分大纲

开发部分大纲

 

第一章    Windows SharePoint Service对象模型介绍

 

第一节    WSS对象模型综述

总体介绍SharePoint的对象模型。SharePoint的对象模型是一套非常完善的对象模型体系,大致整个Web服务器(SPWebServer)、小到一个文件的版本信息(SPFileVersion),甚至一些网站的设置,都可以通过SharePoint的对象模型来进行访问。此外,SharePoint还提供了一些常规功能的类库来补充.NET类库的不足(SPUtilities命名空间)。

通过使用SharePoint的对象模型,可以完成几乎所有SharePoint所支持的功能,SDK中有很多开发的sample,可以进行参考。但是,SDK并不全面,很多有用的东西并没有出现在SDK中,尤其是一些WebControl,这也需要在开发中不断地积累经验,可以参考默认页面中的一些控件的使用,有时甚至需要对dll进行反编译,结合代码自动提示功能来寻找所需要的类(PageInfo)。

Portal很强大,但是通过对若干项目的开发,也不得不承认,在某些方面,SharePoint做得很“严格”(例如权限),所以在确定用户需求的时候,也尽可能考虑到实现上的难度。在SharePoint上,有一些事情是应该做的,有一些是不太容易做到的,也有一些事情是使用一般方法无法做到的。

 

第二节    网站相关的对象模型

本节主要介绍SPSiteSPWeb两个类。

首先,介绍SPSiteSPWeb这两个类的区别与联系,指出在SDK中这两者容易混淆的地方。

·SPSite

         创建一个SPSite对象(构造函数)

         SPSite下的SPWebAllWebs属性和OpenWeb函数)

         在一般的应用中,SPSite只是为了获得SPWeb的一个手段,并不很常用。

·SPWeb

在大多数时候,直接使用的是SPWeb对象,一般也是通过SPWeb对象来获取其他各种对象模型。SPWeb下包含有丰富的对象模型,包括几大部分:列表、文件系统、用户权限系统。

SPWeb对象提供了很多属性,用来获取该网站的一些信息,例如TitleTemplateAuthorID等等。

此外,SPWeb对象还提供了一些函数,用来直接访问其他的对象模型,例如GetViewFromUrlGetFileSearchDocument等。

此外,从本节开始通过sample code对类的成员函数及变量进行演示和说明。在前两章中,均使用Console程序的方式进行演示,为了一目了然地看到结果,同时避开Web页面上的一些复杂机制,以及复杂的权限限制。

[Tip]在编程中,使用try-catch是一个良好的习惯,如果可能的话,尽量对所有可能出错的语句进行try-catch,并且针对每一种不同的错误分别进行处理。SharePoint是一套相对庞大的对象模型体系,有时会遇到一些事先无法预料到的问题,因此,使用try-catch是避免程序意外崩溃的最好的办法。此外,在报错的时候,也尽量使用自定义的报错,使得程序更加友好、更加人性化。

 

第三节    列表相关的对象模型

本节介绍列表相关的对象模型,包括SPListCollection)、SPViewCollection)、SPFieldCollection)、SPListItemCollection)。

·SPListCollection

列表的获取、添加、删除。

·SPViewCollection

         视图的含义和作用,从SchemaXml属性中获取信息。

·SPFieldCollection

         字段的获取、添加、删除;

         字段的两个名称(TitleInternalName);

         SchemaXml属性获取信息(数据库初探);

         默认列表的一些默认字段。

·SPListItemCollection

         列表条目的获取、添加、删除;

         使用SPQuery获取列表条目。

 

第四节    文件相关的对象模型

本节介绍文件系统相关的对象模型,主要包括SPFolderSPFile,另外,对文档库这一特殊的列表进行简要地介绍。

·SPFolder

         文件夹的获取(子文件夹)、添加、删除;

         从其他对象获取文件夹(SPWebSPList

·SPFile

         文件的获取、添加、删除;

         SPWeb直接获取文件

·文档库

         一个特殊的文件夹,可以使用三种不同的对象模型来访问。

 

第五节    用户/权限相关的对象模型

本节介绍用户和权限相关的对象模型,主要包括SPRoleSPUserSPPermission

·SPPermission

SharePoint的权限划分是在API级别的,而不像传统的网站那样在页面级别,这是一把双刃剑——更安全,却也更死板,除非直接从低层的数据库入手,否则无法绕过这一权限系统。因此在执行相应的代码时,最好事先检查权限,或者进行try-catch,以避免不必要的错误。

         WSS下的权限条目,SPRights枚举(PermissionMask);

         简单判断当前用户是否拥有某种权限的方法。

·SPRole

         角色包含用户,给一个角色添加一个用户。

         SPRoleType枚举,每个角色对应的权限

·SPUser

         用户的基本信息;

         用户包含角色,给一个用户添加一个角色。

 

第二章    SharePoint Portal Server对象模型介绍

 

第一节    SPS对象模型综述

PortalWSS的不同之处(需要在前文的综述中提及),两者的侧重点不同。区域(Area)的概念,AreaSPWeb在对象模型上的关系。实际上,在一个Portal的区域中,WSS的大部分对象模型都可以继续使用,但是有一些对象模型,尤其是涉及权限的对象模型,有了很大的变化,这和Portal的侧重点是有关系的。

Portal的对象模型体系更为庞大,因为它本身也更加复杂,但在一般场合的实际的应用中,我们所能接触到的内容并不多。

[Tip]Portal对象模型的一大特点:xxxxManager

 

第二节    门户/区域相关的对象模型

·在Portal中获取一个区域,以及该区域对应的SPWeb对象的方法

         Console程序中,获取一个区域是相对很麻烦的事情;

         通过区域可以获取一个SPWeb,也可以按照原来的方法获取它;

·Area

         Area的一些属性和可自定义的特性;

         Area清晰的层级结构。

 

第三节    门户列表相关的对象模型

门户列表是一个Portal所独有的对象,Portal的最大特点也正体现在门户列表中,本节主要介绍门户列表的获取、添加、删除,并介绍门户列表的可自定制性。因为门户列表结构的固定性(需要在前文的综述中提及),它可以自由地在不同区域之间转移,这一点在对象模型中非常清晰的体现出来(获取方式、修改所属区域的方便性)。

AreaListing之外,有一些与之相关的对象模型,例如:访问群体(Audience)、组(AreaGroup)。

 

第四节    用户/权限相关的对象模型

用户/权限系统,是PortalWSS另外一个最不同的地方。

Portal下,用户直接与AD相关。使用UserProfile可以获取用户在AD中设置的属性,SPUser对象依然可以使用。

但是在权限方面,Portal上无法再使用WSS中的对象模型,尤其是SPRole。在Portal中,权限划分的粒度较粗(需要在前文的综述中提及)。使用AreaAccessChecker来检验当前用户的权限。Portal下的权限:PortalRight枚举。

初步涉及到ExternalSecurity的概念。

 

第三章    WebPart开发

 

第一节    WebPart综述

WebPart介绍(需要在前文的综述中提及)的补充,WebPart在对象模型中是继承自WebControl的,在SharePoint中,依然可以使用传统的WebControl,对比传统的WebControlWebPart,介绍在何种时候采用哪种控件比较方便。

简要地介绍一下WebPart及相关部件(WebPartZone)在对象模型中对应的类,以及几种默认的WebPart

 

第二节    创建WebPart

手工创建一个最简单的WebPartHelloWorld,只使用最必要的RenderWebPart函数。手工将其布置到服务器中。

然后在此WebPart中使用一个控件(例如文本框),介绍CreateChildControls函数。

最后,介绍VS.NETWebPart模板,使用该模板创建WebPart会更加方便,但仍然需要手工进行部署。

[Tip]WebPart的编程中,非常容易忽略的一点:在RenderWebPart函数中,是无法保存对类的成员变量的修改的。

 

第三节    WebPart中对象模型的变化

本节主要介绍在WebPart这一具体的使用环境中,对象模型发生了哪些变化。

首先,获取当前网站可以使用SPControl这个类,而不必麻烦地按照url来获取(当然,这种获取方式依然是起作用的);

Portal中,获取PortalContext的方式也更加直接,但是,如果想直接获取当前的区域,有两种方法:标准的方法是,修改继承,使用PortalBaseAreaWebPart作为父类,并使用它的成员变量来获取当前区域的GUID;或者使用一个在任何文档中都没有提到的类PageInfo来获取(建议使用,因为它可以在构造函数的时候就获取到当前区域,而前面的方式只能在Render的时候才正常获取到)。

Render中修改列表内容的时候,需要将SPWebAllowUnsafeUpdate设置为true

WebPart中使用对象模型,需要根据级别在web.config中设置不同的TrustLevel

[Tip]WebPartFrontPage中可以被编辑,如果无法编辑,可能是由于在IIS中设置了地址或者主机头。介绍WebPart中负责设计时显示的一个接口。

[Tip]在本节的最后,会介绍一个非常有意义的控件FormDigest。该控件在WebPart编程中不会用到,所以经常被忽略,但是在编写aspx页面使用SharePoint对象模型的时候会遇到很大的问题。

 

第四节    WebPart自定义属性

首先,从WebPart模板创建的默认WebPart入手,介绍WebPart的自定义属性,并介绍如何编写其他类型(整型、bool型、枚举型)的自定义属性。在属性设置窗口中,为每中类型的属性都设置了默认的控件进行编辑修改。

[Tip]在设置属性的时候,尽量使用简单的类型。

[Tip]在属性的set方法中,可以对属性的值进行控制和修改,以免出现不必要的错误。也应该保证属性之间都是互相独立的,不要有相关性。

通过实例了解SaveProperty变量,了解在代码中设置属性值的方法和需要注意的事项。

 

第五节    WebPart连接

首先通过两个默认的WebPart让用户了解什么是WebPart连接。

通过一个最简单的实例,了解创建WebPart连接的过程,在VS.NET模板中,也支持创建WebPart连接的模板。由于篇幅关系,只介绍最简单的一组ProviderConsumer

WebPart连接的优点:比较专业,一个页面中可以有多组连接,可以在FrongPage中进行编辑;缺点:编程相对复杂。因此,对于一些比较简单的应用场景,可以利用Url传递参数的方式来进行。

[Tip]在使用Url进行传递的时候,注意中文的编解码。

 

第六节    WebPart的自定义设置栏ToolPart

默认的自定义属性显示在属性设置面板中,但是功能有限,而且形式单一,也无法进行内部的关联(例如填入一个列表名称后,再选择它的几个视图/字段)。如果需要更复杂的功能,就需要使用自定义的ToolPart类来完善。

ToolPart类中,编程的方式和WebPart的编程方式基本是相同的,注意多了三个重要的函数。此外,在保存属性的时候,因为SaveProperyWebPartprotected类型成员变量,外部的类无法直接访问,需要在WebPart的类中再添加一个public函数来完成。

通过一个简单的例子(调用高级编辑器设置一段多行带格式的文本,并保存为属性)来说明该栏的简单写法。

[Tip]虽然默认的属性可以设置分组,但是分组的顺序是无法修改的,然而ToolPart却可以自定义显示的顺序。

 

第七节    WebPart的自动部署

从第二节可以看到,手工的部署一个WebPart是比较麻烦的,而且很容易出错,本节介绍几种自动部署WebPart的方式。

利用MakeCab.exe制作cab压缩包,然后通过stsadm.exe来进行部署。Stsadm.exe是一个非常有用的命令行工具,可以完成很多基本的功能,在编写其他程序(尤其是在服务器本机运行的程序)的时候,可以调用该命令,执行一定的功能。

制作MSI安装包,这种方式较上者来说更为方便,也是很多WebPart发布的方式,它内部实际上是自动执行了上面那种方式的部署方案。介绍WPPackage.exe命令行工具的使用。

其他现有工具的使用(例如InstallAssemblyWPManager),提供友好的界面,可以直接对dll进行操作,不用编写比较复杂的dwpmanifest.xml文件。实际上,也是使用程序执行了cab安装的功能。

[Tip]如果需要布置到GAC中,则需要对WebPartdll进行强命名,介绍强命名的方法和dwp文件中不同的写法。

 

第八节    WebPart的调试

在实际的程序编写过程中,可以体会到,WebPart的调试是非常麻烦的,虽然会利用try-catch的方法进行异常的捕获,但是有一些时候还是会引发意料不到的错误。除了在页面上输出调试信息这种办法之外,也可以对web.config进行修改,显示asp.net页面传统的报错方法,而不会重定向到SharePoint自己的报错页面。

此外,如果是在服务器本机进行调试,也可以在VS.NET开发环境中附加在w3wp进程中进行单步调试。这使得WebPart的调试和传统程序的调试方法一致化。

如果是在远程进行调试,同样可以通过一些配置进行单步的调试,但是配置方案相对比较复杂,在本书中就不再涉及了,有兴趣的读者可以参阅一些文章

 

第四章    高级开发

 

第一节    更轻松的WebPart开发

在实际的应用中,WebPart开发中所遇到的最大问题就是它的界面样式不能进行可视化的设计。而通过SmartPart和另外一个WebPart,用户就可以直接在VS.NET中可视化地设计用户控件(UserControl),并在上述WebPart中引用该用户控件便可以了。

该方法的优点是比较灵活,可以进行可视化的设计,对于界面性、交互性较强的WebPart开发比较方便;它的缺点也是显而易见的,不能自定义属性。因此在实际的应用中,究竟选取哪种开发模式,是需要根据WebPart的需求来考虑的。

 

第二节    多语言的WebPart开发

多语言的程序已经成为当今程序的一个潮流和发展方向,如何让一个WebPart可以正常工作在多种语言的环境中,并且在界面上可以显示相应的语言?本节通过一个简单的实例来说明如何开发、部署一个多语言的WebPart

 

第三节    WebService的使用

SharePoint平台提供了一套非常庞大的对象模型体系,但是在网络平台上,使用这种对象模型编程一般是必须要在WSS或者SPS上来进行的,但是这种平台又有着诸多不便。如何能在普通的网站或者应用程序中,尤其是在没有SharePoint环境的机器上运行这样的程序,取获取其他SharePoint网站的内容?

SharePoint平台同样提供了一套比较完善的WebService,可以让其他程序从网络上调用该WebService来完成操作。

本节通过一个简单的实例介绍了WebService的基本用法, 并简要地介绍一下SharePoint中默认提供的WebService所在的url和它们的基本功能。

 

第四节    文档库的事件触发机制

文档库在SharePoint中是一个比较特殊的对象,它即是列表,又是文件系统,此外,为了便于文档的管理,SharePoint还为文档库提供了事件触发的机制。

本节通过一个实例,介绍如何捕获文档库的事件,以及获得事件的一些属性和针对该事件进行的操作。

 

第五节    SharePoint的底层数据库

通过使用对象模型,可以完成SharePoint中的绝大部分操作,但是由于SharePoint体系本身的限制,有些时候使用对象模型也是不方便的(尤其对于权限的限制)。这个时候,可以直接绕过对象模型,对底层的数据库直接进行读取,该方法也使用于一个非SharePoint的网站来获取一个SharePoint网站的内容。

本节主要介绍数据库中几个重要的表的结构和它们的含义:CatDef(区域定义)、CatJoint(门户列表)、UserData(普通列表)、UserInfo(用户信息)、WebGroupMembership(网站角色)、Webs(网站定义)等等。

因为直接读取数据库不需要在SharePoint上进行权限的验证,因此出于安全性考虑,在使用数据库的时候,一般只进行读操作。除非必要情况,不建议直接改写(尤其是添加)数据表的条目。

你可能感兴趣的:(SharePoint)