博客园_流星小筑

Sharepoint门户可以干很多事情的

2011-01-20T12:55:00Z

09年协助MS epg打单时开发的POC，其实在07年我就干过这些活了。不过感触最深的还是打单的对比，ibm是用所有客户要求的需求功能点讲一个story，我们这边是这些功能点俺家都有。虽然我觉得既然自己参与了，就要帮助赢下IBM，可我只是过来帮忙的，没法去控制参与的所有人按讲一个story来完成目标。

一、门户集成Domino邮件及代办。

2、使用sharepint实现Domino全文搜索效果

3、集成的Domino待办通过OCS进行即时消息通知。

本文链接

利用 Lotus Notes API 提高自动化测试效率(转)

2011-01-15T01:08:00Z

自动化测试可以很大程度的减少人工参与的工作量，提高测试效率。在自动化测试中，测试人员经常需要与 Notes/Domino 数据库打交道，比如说在自动化测试之前，需要从测试用例数据库中挑选出哪些测试用例要被执行；在测试完成之后，需要将测试结果记录到测试用例数据库，或者将测试报告存放到 Notes 某一指定的数据库中，通常这些工作是由手工完成。如果将这些工作自动化，将会很大程度上节约测试时间和测试成本。幸运的是，Lotus Notes/Domino 为程序员提供了一系列 C++/Java API，利用这些 API 可以完成对 Notes 数据库的访问、创建、管理等几乎所有的操作。本文将介绍利用 Lotus Notes API 进行编程，自动操作 Notes/Domino 数据库，使整个测试过程自动完成。

图 1 说明了自动化测试的整体流程：首先从 TCDB 中提取符合条件的测试用例，然后在指定测试机上安装被测软件、执行挑选出来的测试用例、生成测试报告，然后将测试结果回填到 Testcase DB 中，并且将测试报告发送到指定数据库中。

图 1.

回页首

Notes/Domino C++ API 在自动化测试中的应用

C++ API 是在对 Notes C API 进行封装的基础上建立的。由于 C++ 语言的面向对象的特性，所以 C++ API 使用起来更简单一些。

在使用 Notes C++ API 进行编程之前，根据你当前使用的 Notes 版本，需要下载匹配版本的 C++ API Toolkit, 这个工具箱可以从 IBM 网站上得到。该工具箱中包含有 API 帮助文档、库文件、头文件、示例程序以及示例程序中用到的数据库文件等。

配置 Visual C++

在利用 Notes C++ API 进行编程之前，需要先配置 Visual C++，环境配置正确才能保证代码能够正常编译链接。

将 Notes 的安装路径添加到环境变量 path 中。
在 VC 中新建一个 C++ 工程 NotesDemos, 然后新建一个 C++ 文件。
选择菜单 Build >Set Active Configuration > Win32 Release > OK
将 C++ API（notescpp）路径添加到 lib 和 include 中
选择 Project>Add to Project>Files, 将 notesCpp.lib 添加到工程，如图 2 所示：

图 2.

利用 Notes/Domino C++ API 编程

接下来介绍如何利用 Notes C++ API 访问 Notes, 并对 Notes 数据库中的文档进行操作。

代码清单 1 是个简单的例子程序，目的是得到某个数据库名字。

清单 1.

#include <lncppapi.h> 
 #include <iostream.h> 
 void main(int argc, char *argv[]) 
 { 
 char errorBuf[256]; 
 LNNotesSession session; 
 LNSetThrowAllErrors(TRUE); 
 LNDatabase db; 

 session.Init(); 

 try{ 
 session.GetDatabase(nsfFileName, &db, server); 
 db.Open(); 
 cout <<"DB title: "<< db.GetTitle() <<endl; 
 }catch (LNSTATUS error){ 
 LNGetErrorMessage(error, errorBuf); 
 cout<<"Error: " <<errorBuf <<endl; 
 } 
 db.Close(); 

 session.Term(); 

 return; 
 }

其中：

lncppapi.h：在利用 Notes API 编程时，一定要包含该头文件。这个文件位于 NotesCPP\Include 目录下，通过该头文件链接到其他的定义所有 API 对象和数据类型的类库。比如 LNNotesSession 类就定义在其中。

Session.Init: 初始化 C++ API，建立与 Notes 的连接，读取 notes.ini 文件，找到当前 Notes 用户 ID。当与 Notes 建立连接之后，就可以操作 Notes 数据库了。

session.term: 在对 notes db 操作完成之后，调用该函数切断与 Notes 的连接、释放资源。

GetDatabase( const LNString &path, LNDatabase *db, const LNString &server = "" ) ：其中参数 NSF 文件名和服务器的 hostname 可以通过查看数据库的属性得到，如图 3 所示：

图 3.

数据库中的每个文档属性（通过右键单击可得到）都是由不同的域组成，通过这些域可以唯一的确定一个文档，我们通过改变域的值对其进行操作。文档属性如图 4 所示：

图 4.

自动化测试完成之后，测试报告可以自动存放到指定数据库的指定目录下，清单 2 演示了如何对数据库中的文档进行操作。该代码片断目的是先在指定的数据库中新建文档，然后将测试报告导入到该文档中，这样使测试报告更加直观。当然，也可以通过调用

LNRichText::CreateAttachment（）方法把测试报告以附件的形式贴在该文档中。

清单 2.

Session.Init(); 
 Session.GetDatabase(nsfFileName, &Db, server);   // 连接指定数据库 . 

 LNText      Author, Categories, Subject, DocumentType; 
 LNDocument  NewDoc, NewRes; 
 Db.Open(); 
 // 首先查找主文档，然后使测试报告对该文档进行回复
 SearchFormula = "Subject = \""; 
 SearchFormula += mainDocSubject; 
 SearchFormula += "\"";     

 // 如果找到没有主文档，则新建一个类型为“MainTopic”的文档。 Search（）方法，找到文档，返回为 0. 
 if (Db.Search (SearchFormula, &DocResponseTo)) 
 { 
     Db.CreateDocument(&NewDoc, "MainTopic"); 
     Subject.SetValue(mainDocSubject); 
     Author.SetValue("CN=Jing Xing/OU=China/O=IBM"); 
     Categories.SetValue(Category); 
     DocumentType.SetValue("Reference"); 
    
     // 为文档不同的域设值
     NewDoc.CreateItem("From", Author, LNITEMFLAGS_SUMMARY);
     NewDoc.CreateItem("Subject", Subject, LNITEMFLAGS_SUMMARY);
     NewDoc.CreateItem("Categories", Categories, LNITEMFLAGS_SUMMARY); 
     NewDoc.CreateItem("DocType", DocumentType, LNITEMFLAGS_SUMMARY); 
     NewDoc.ComputeWithForm(true); 
     NewDoc.Save();// 保存文档
 } 

 // 创建文档 , 类型为 Response 
 Db.CreateDocument(&NewRes, "Response"); 
 Subject.SetValue(subSubject); 
 Author.SetValue("CN=Jing Xing/OU=China/O=IBM"); 
 Categories.SetValue(Category); 

 NewRes.CreateItem("From", Author, LNITEMFLAGS_SUMMARY); 
 NewRes.CreateItem("Subject", Subject, LNITEMFLAGS_SUMMARY); 
 // 如果分类不存在，则新建 category 
 if(Category!="") 
 { 
     NewRes.CreateItem("Categories", Categories, LNITEMFLAGS_SUMMARY); 
 } 
 NewRes.CreateItem("ShowAuthors", ShowAuthors, LNITEMFLAGS_SUMMARY); 
 NewRes.MakeResponse(NewDoc); // 对 NewDoc 进行回复

 RT.Append("Here is the report: \n\n"); 
 RT.GetEndCursor(&BeginCursor); 
 RT.Import(ReportLocation, &BeginCursor);// 将 report 文件导入新建文档中。
 NewRes.CreateItem("Body", RT); 

 NewRes.Save(); 

 Db.close()；
 Session.term();

其中每个函数的具体用法可以参考 NotesAPP 中提供的帮助文档。

回页首

Notes/Domino Java API

同 C++ API 一样，Notes Java API 也可以完成对 Notes/Domino 数据库的大部分操作。不同的是，Java API 使用起来相对更简单一些，不用配置很多的东西，只需要将 ${Notes}/jvm/lib/ext/notes.jar 包含在 classpath 中即可。关于 Java API 的帮助文档可以参考：IBM Lotus Notes and Domino 信息中心。

下面以一段简单的例子说明如何通过 Java API 连接数据库 , 清单 3 是访问某个数据库 , 然后输出该数据库的名字。

清单 3.

Public static void main(String args[]){ 
    try{ 
        NotesThread.sinitThread(); // 启动线程
        Session session = NotesFactory
            .createSession((String)null, (String)null, password);
        Database database = session.getDatabase(host, nsf, false);// 连接数据库
        System.out.println("DataBase tilte is: " + database .getTitle()); 
    } finally { 
        NotesThread.stermThread(); // 结束该线程
    } 
}

其中：

NotesThread.sinitThread()：对 Notes/Domino 作本地调用时初始化进程。
NotesThread.stremThread(): 结束该调用。
Session.getDatabase(String server, String db, boolean createonfail)：该方法与 C++ 的类似，需要提供要访问的服务器 hostname 和数据库 nsf 文件名。同样，可以通过查看数据库属性得到。

正如前文提到的，自动化测试时需要从测试用例数据库中选出符合条件的测试用例后自动执行。以下代码清单 4 是从数据库中选出 cycle-001 中所有的执行方法为 Automated 的测试用例，并将其组织成一个测试用例集保存于 .suite 文件中。

清单 4.

String cycle = "CYC-001"; 
 try { 
     NotesThread.sinitThread(); 
     File file = new File("C:/cyc-001.suite");// 该文件用于保存符合条件的测试用例的 ID 
     if (file.getParentFile() != null) 
         file.getParentFile().mkdirs(); 
     suiteFileWriter = new BufferedWriter(new FileWriter(suiteFile)); 
    
     Session session = NotesFactory
         .createSession((String)null, (String)null, notesPassword);
     Database database = session.getDatabase(host, nsf, false); 
     DocumentCollection dc = database
         .search("ExecCycleID=" + "\"" + cycle + "\"");// 搜索所有属于"CYC-001"的测试用例。
     Document doc = dc.getFirstDocument(); 
     while (doc != null) { 
         String method = doc.getItemValueString("Method"); // 得到域”Method”的值
         String tcID = doc.getItemValueString("ExecTCID"); 
         if ("Automated".equals(method)) { 
             suiteFileWriter.write("tcID.replace("-", "_") + "\r\n"); 
             } 
         } 
     } 
 } finally { 
     NotesThread.stermThread(); 
     if (suiteFileWriter != null) 
         try { 
             suiteFileWriter.close(); 
         } catch (Exception e) { 
         } 
     } 
 }

回页首

总结

本文介绍了在自动化测试中使用 Notes/Domino 提供的 API 来访问 Notes/Domino 数据库，并进行数据库中文档操作，使在自动化测试中的很多工作可以自动完成。不管使用 Notes C++ API 还是 Java API，都能很好的完成自动化测试时对 Notes/Domino 数据库的操作需求，这大大地增加了测试的自动化程度，节约了测试成本。

本文链接

sharepoint2010,I am coming!

2010-12-12T15:21:00Z

之前帮某微软金牌合作伙伴做poc,短暂的接触了一下2010.现在,终于正式在自己搭好的虚机里,开始了2010之旅.

相比kaneboy, 杜伟,我来得太晚了,but better later than never.

首先是可视化Webpart部件无法搭建沙盒解决方案.因为可视化Web部件包含.ascx控件,而沙盒解决方案不能部署文件到Web前端上.

其次是报"沙盒无法启动新的解决方案服务的SPUserCodeV4 "的错误.在管理中心启动沙盒解决方案服务即可.

本文链接

sharepoint安全性验证无效的一个问题

2010-10-01T05:44:00Z

之前遇到过这个问题。今天十一碰到客户开了这个case,Eric做了解答。sharepoint有些内容真的很bt的说

十一™ 说:
幫我做case
客戶寫了段代碼
new Item 之後，做item.update
然後又去改 permission
然後報錯
Microsoft.SharePoint.SPException: 對於這個網頁的安全性驗證無效。請按一下網頁瀏覽器的 [上一頁]，重新整理頁面，然後再次嘗試作業。
在 ListItem.RoleAssignments.Add( ) 報錯
Eric 说:
allowunsafeupdate=true
十一™ 说:
設了
Eric 说:
update之后还要设置一次
十一™ 说:
是喔?
為什麼?
Eric 说:
必须的！
十一™ 说:
update 完會變 false ?
Eric 说:
因为update()之后会被重置
对
十一™ 说:
faint
有文件說嗎?
Eric 说:
不知道。。。
还有个歪招。
十一™ 说:
喔?
Eric 说:
在执行之前，把current httpcontext存到另一个变量
完了把current设置成null
就不会有安全性检查了。操作完了再设置回去，哈哈

本文链接

REST实现原理浅析(转载)

2010-09-28T02:28:00Z

REST 首先只是一种架构样式，不是一种标准。这点和 Ajax 类似，两者都是利用现有的成熟技术。在 REST 的定义中，一个 Web 应用总是使用固定的 URI 向外部世界呈现（或者说暴露）一个资源。

注：URI 是英文 Uniform Resource Identifier 的缩写，中文翻译“通用资源标志符”。“通用资源标志符”是指唯一标识一个资源（xhtml 文件、图片、css 样式表）的字符串。当然了，RFC 中定义的 URI 复杂得多，不过我们此处将 URI 想象成一个人的身份证号码就行了（你不能有两个同时有效的身份证号码，一个号码也不可能同时对应两个人）。而我们天天挂在嘴边的 URL 地址就是 URI 的一种表现形式（个人理解，有错请纠正）。

知道什么是URI 后，我们来看一个实际例子：

http://www.example.com/photo/logo 指向 example.com 网站（可以视为一个 Web 应用）中类型为 photo，名字为 logo 的资源。我们用浏览器访问这个URI，看到的将可能是一个 xhtml 文档，其中用＜img src=”……” /＞来显示实际的照片。

http://www.example.com/photo/logo 很容易让你想到 URL 重写。事实上，这个地址很可能会在服务器内部处理为 http://www.example.com/photo.php?name=logo 这样的地址。photo.php 是服务器端的一个动态脚本文件，根据 name 参数生成 xhtml 文档返回给浏览器。

现在假设我们要获取这张照片的 XML 文档。XML 文档中包含照片的文件名、文件大小、拍摄日期等等信息。也就是说我们要获取“同一个资源的不同表现形式的数据”。对于这个要求，我们可以很容易的用另一个 URL 地址达到：http://www.example.com/xml/logo。

但是，这就违背了“URI 唯一标识一个资源”的定义。如果我们要获取同一个资源的多种表现形式，那么就要使用更多的 URL，从而给一个资源指定了多个不同的 URI。

而在 REST 中，不管是获取照片的 xhtml 文档还是 XML 文档，或者照片文件本身，都是用同一个 URI，就是 http://www.example.com/photo/logo。

那这是怎么办到的呢？Ruby On Rails 中是通过分辨 HTTP Request Header 信息来分辨客户端是想要取得资源的哪一种表现形式的数据。

当我们用浏览器访问一个网址时，浏览器会构造一个 HTTP 请求。这个请求有一个头信息，其中包括了本次请求接受何种类型的数据。通常浏览器发送的 HTTP 请求头中，Accept 的值都是 */*，也就说接受服务器返回的任何类型的数据。

看到这里，聪明的家伙应该知道了。只要我们指定一个特定的 Accept 参数，那么服务器就可以通过判断该参数来决定返回什么类型的数据。所以在一个采用 REST 架构的应用中，要获取同一个资源的不同表现形式的数据，只需要使用不同的 HTTP 请求头信息就行了。

如果考虑为 Web 应用增加 Web Services，这种技术的价值就体现出来了。比如我写了一个 Delphi 程序，现在只需要构造一个包含 Accept: text/xml 的 HTTP 请求头，然后将请求发送到 http://www.example.com/photo/logo 就可以了。返回的结果就是一个 XML 文档，而不是 xhtml 文档。

因为我们的 HTTP 请求头信息有不同的状态，从而可以获得不同的数据，所以叫做“具象状态传输” :)

除了上面的用法，REST 还有进一步的扩展。

我们在 Web 应用中处理来自客户端的请求时，通常只考虑 GET 和 POST 这两种 HTTP 请求方法。实际上，HTTP 还有 HEAD、PUT、DELETE 等请求方法。而在 REST 架构中，用不同的 HTTP 请求方法来处理对资源的 CRUD（创建、读取、更新和删除）操作：
◆POST: 创建
◆GET: 读取
◆PUT: 更新
◆DELETE: 删除

经过这样的一番扩展，我们对一个资源的 CRUD 操作就可以通过同一个 URI 完成了：
http://www.example.com/photo/logo（读取）
仍然保持为 [GET] http://www.example.com/photo/logo

http://www.example.com/photo/logo/create（创建）
改为 [POST] http://www.example.com/photo/logo

http://www.example.com/photo/logo/update（更新）
改为 [PUT] http://www.example.com/photo/logo

http://www.example.com/photo/logo/delete（删除）
改为 [DELETE] http://www.example.com/photo/logo

从而进一步规范了资源标识的使用。

通过 REST 架构，Web 应用程序可以用一致的接口（URI）暴露资源给外部世界，并提供对资源的操作服务。这对于以资源为中心的 Web 应用来说非常重要。例如照片共享网站、用户社区等。

本文链接

山人自有妙招－sharepoint正式环境不能调试

2010-08-20T01:28:00Z

最近在做的sharepoint项目上，测试服务器上开发的内容，特别是eventHandler等，在正式环境中却会经常发现没有效果，又不能调试。很郁闷。

这个项目中，我们集成了腾讯通的消息提醒功能，走流程审批，发会议通知等都会有消息提醒。所以我就加了一个try,catch，将错误信息通过腾讯通发个消息给我自己。

本文链接

Sharepoint ListType Id

2010-07-27T03:10:00Z

备忘：

List Id	List Description
100	Generic list
101	Document library
102	Survey
103	Links list
104	Announcements list
105	Contacts list
106	Events list
107	Tasks list
108	Discussion board
109	Picture library
110	Data sources
111	Site template gallery
112	User Information list
113	Web Part gallery
114	List template gallery
115	XML Form library
116	Master pages gallery
117	No-Code Workflows
118	Custom Workflow Process
119	Wiki Page library
120	Custom grid for a list
130	Data Connection library
140	Workflow History
150	Gantt Tasks list
200	Meeting Series list
201	Meeting Agenda list
202	Meeting Attendees list
204	Meeting Decisions list
207	Meeting Objectives list
210	Meeting text box
211	Meeting Things To Bring list
212	Meeting Workspace Pages list
301	Blog Posts list
302	Blog Comments list
303	Blog Categories list
1100	Issue tracking
1200	Administrator tasks list

本文链接

使用 SharePoint 2007 进行安全性编程(转)

2010-06-16T03:10:00Z

Office Space

使用 SharePoint 2007 进行安全性编程

Ted Pattison

代码下载位置: OfficeSpace2008_02.exe (209 KB)
Browse the Code Online

外部安全主体和 SPUser 对象
添加已通过身份验证的用户和外部用户
使用权限级别
WSS 组
标识、提升和模拟
安全对象
结束语

您可能已经对使用 Windows® 和 ASP.NET 的安全性进行安全编程的基础有所了解，但您对 Windows SharePoint® Services 3.0 (WSS) 增加的安全保护又了解多少呢？在本期的 Office Space 专栏中，我将重点介绍 WSS 引入的一些新的安全术语和概念，并为您展现一个使用 WSS 对象模型实现安全编程的新世界。

建议您下载本专栏附带的示例项目，并按照本专栏其他部分提供的代码执行操作。该项目已配置为在构建过程完成之后运行一个批处理文件，该批处理文件会将所有的项目组件编译成一个 WSS 解决方案包，并在本地 WSS 服务器场中安装该包。在建立项目并安装解决方案之后，您可以浏览任意网站集，并启用针对网站集的名为“Security Demo”的功能。然后您就可以通过“网站操作”菜单导航到自定义应用程序页，这些页面通过一些代码演示了 WSS 安全编程技术。

外部安全主体和 SPUser 对象

大多数安全模型都是基于安全主体的。每个安全主体均表示一个用户或一个组。用户拥有帐户，并通过这些帐户进行身份验证。身份验证完成后，每位用户将获得一个身份标识。当用户使用 Windows 帐户进行身份验证时，您可以使用 System.Security 命名空间中的 Microsoft® .NET Framework 安全类来检索身份标识，该标识回指到特定的 Windows 帐户并允许您查看该用户的登录名：

复制代码

WindowsIdentity identity = WindowsIdentity.GetCurrent();

string WindowsLogin = identity.Name;

使用 WindowsIdentity，您可以动态地创建一个 WindowsPrincipal，该对象允许您通过测试查看当前用户是属于 Active Directory® 组还是本地 Windows 组，如下所示：

复制代码

WindowsIdentity identity = WindowsIdentity.GetCurrent();

WindowsPrincipal principal = new WindowsPrincipal(identity);

if( principal.IsInRole(@"LITWAREINC\AllFTE") ){

// perform operation allowed for fulltime employees

}

ASP.NET 同时支持 Windows 身份验证和基于表单的身份验证 (FBA)。ASP.NET 中的 User 对象通过基于 IPrincipal 接口（而非 WindowsPrincipal 类）进行建模的方式摆脱了对 Windows 帐户的依赖性。ASP.NET 运行库根据当前用户是使用 Windows 帐户还是使用 FBA 帐户进行身份验证，来动态创建不同类型的 IPrincipal 对象：

复制代码

IPrincipal AspUser = HttpContext.Current.User;

string AspUserName = AspUser.Identity.Name;

ASP.NET 的 User 对象还提供了使用 IsInRole 方法检查用户是否属于特殊角色的方式。对于 Windows 用户，IsInRole 方法让您能够查看当前用户是否为 Active Directory 组的成员。如果您使用的是 ASP.NET 角色提供程序附带的 FBA 帐户，也可以使用 IsInRole 方法来检查是否已将 FBA 用户添加到特定的 ASP.NET 角色：

复制代码

IPrincipal AspUser = HttpContext.Current.User;

if(AspUser.IsInRole("Site Administrators") {

// perform privileged operation

}

身份验证操作会生成某种形式的回执，系统在运行时使用该回执来表示用户身份，以及对组或角色中的成员资格进行跟踪。如果用户使用 Windows 帐户进行身份验证，则身份验证的回执为 Windows 安全令牌。如果用户使用 FBA 帐户进行身份验证，则身份验证的回执为由 ASP.NET 运行库和特定身份验证提供程序创建的一个 HTTP Cookie。

了解 WSS 不支持用户身份验证这一点是十分重要的。但 WSS 可以利用各种 ASP.NET 身份验证提供程序提供的底层身份验证组件。WSS 对于网站安全保护的价值在于它能够对授权和访问控制进行配置。WSS 能够在网站集范围内对外部安全主体（例如，Windows 用户、FBA 用户、Windows 组和 ASP.NET 角色）进行跟踪。借助 WSS，您还可以配置分配给这些外部主体的权限，实际上是授予用户访问 WSS 安全对象（例如网站、列表、项和文档）的权限。

请注意，网站集在配置授权和访问控制时发挥了极其重要的作用。在跟踪外部主体和配置权限时，WSS 将每个网站集视为其彼此独立的孤岛。WSS 的高级设计有意将每个网站集隔离开来，以便一个网站集中的用户安全设置不会影响到其他网站集中的权限或访问控制策略。

1、SPUser

WSS 对象模型使用 SPUser 对象来表示外部安全主体。您可以通过当前的 SPWeb 对象检索当前用户的 SPUser 对象：

复制代码

SPWeb site = SPContext.Current.Web;

SPUser user = site.CurrentUser;

string DisplayName = user.Name;

string Login = user.LoginName;

string EMail = user.Email;

string User Notes = user.Notes;

SPUser 对象公开了外部安全主体的各种属性，例如，登录名、显示名称和电子邮件地址。将外部主体添加到网站时，通常可以从底层用户存储库（例如 Active Directory 域）中检索到这些属性。SPUser 对象还提供了用于跟踪特定于 WSS 的元数据的属性，例如“注释”字段。

WSS 将外部用户、组和角色的配置文件数据保留在隐藏列表（称为“用户信息列表”）中。WSS 每次提供新的网站集时，会在首要站点中自动创建“用户信息列表”作为隐藏列表。然后，当首次为主体分配权限时，或主体首次通过安全检查访问安全对象时，WSS 会为每个外部主体添加一个新的配置文件。请注意，“用户信息列表”中存储的用户配置文件不能跨网站集进行扩展 － 用户更新一个网站集中的配置文件设置后，不会对其他网站集中该用户的配置文件设置造成更改。

另一个易混淆的地方就是 SPUser 对象通常并不总是代表实际用户。SPUser 对象也可以代表 Active Directory 组和 ASP.NET 角色。WSS 不仅跟踪“用户信息列表”中每种外部主体的配置文件，而且还跟踪外部用户的配置文件数据。

SharePoint 安全模型的许多编程方面的内容都是通过 SPWeb 对象在网站级别公开。如果您要查看哪些用户是当前网站的成员，就会发现这一点。一个 SPWeb 对象可公开三种不同的用户集合，如以下代码段所示：

复制代码

SPWeb site = SPContext.Current.Web;

SPUserCollection c1 = site.Users;

SPUserCollection c2 = site.AllUsers;

SPUserCollection c3 = site.SiteUsers;

Users 集合是三个集合中包含成员最少的集合。该集合包含了当前网站中所有已显式分配了权限的外部主体。

AllUsers 集合包括 Users 集合中的所有成员，以及通过组或角色成员资格使用隐式权限访问过网站中的对象的外部用户。例如，假定名为 Brian 的用户（登录名 LITWAREINC\BrianC）从未被显式授予访问某个网站和查看特定列表的权限。但他也许仍可以查看列表，因为他所属的 Active Directory 组已被配置了列表查看权限。当 Brian 首次访问网站或其中任一对象（比如，使用隐式权限查看一个列表）时，他会被添加为 AllUsers 集合的成员，但不会被添加为 Users 集合的成员。

SiteUsers 集合是包含了当前网站集中每个 AllUsers 集合的成员的一个聚合。该集合的成员包括所有已分配了对网站集中所有对象的访问权限的外部主体，以及所有已被授予使用隐式权限访问网站集中所有对象的权限的外部用户。

添加已通过身份验证的用户和外部用户

那么，如何为使用 Active Directory 帐户通过身份验证的用户创建新的 WSS 用户配置文件？如果您需要创建一个自定义用户界面组件，让标准用户或网站集所有者能够从 Active Directory 域中选择用户或组，您确实应该了解一下 PeoplePicker 控件的用法（参见图 1）。这是 WSS 附带的一个便捷、可重用的控件类型。您可以使用如下的控件标记将此控件添加到自定义应用程序页或 User 控件：

图 1 PeoplePicker 控件 (单击该图像获得较大视图)

复制代码

<SharePoint:PeopleEditor

ID="pickerPrincipal"

AllowEmpty="false"

ValidatorEnabled="true"

MultiSelect="false"

SelectionSet="User, SecGroup, DL"

Width="280px"

runat="server" />

在此示例中，我对 PeoplePicker 控件进行了配置，为 SelectSet 属性分配了 User、SecGroup 和 DL 三个值。通过配置这些 SelectSet 设置，该控件可以让用户根据 Active Directory 选择和解析用户、组或通讯组列表。

您可以通过编程方式访问 PeoplePicker 控件属性，以便在用户使用该控件选择一个或多个安全主体后检索基本帐户的相关登录帐户名。然后，您可以编写代码来实际将这些主体添加为网站成员并为其配置访问权限。

现在，我来介绍如何将外部用户或组添加为网站成员。简单了解 WSS 对象模型之后，您可能会认为只需将外部安全主体直接添加到某个 SPUser 集合（例如 SiteUsers）即可：

复制代码

SPWeb site = SPContext.Current.Web;

site.SiteUsers.Add(@"LITWAREINC\BrianC",

"brianc@litwareinc.com",

"Brian Cox",

"Notes about Brian Cox");

site.SiteUsers.Add(@"LITWAREINC\AllFTE",

"allFTE@litwareinc.com",

"All Full-time Employees",

"Notes about FTE DL");

尽管这种方法确实能够在“用户信息列表”中为外部主体创建配置文件，但由于无法分配权限，因此对安全性几乎没有作用。相比之下，添加新的外部安全主体的一个更好的方式是要对权限进行分配，以便用户有权访问当前网站。但首先您需要学习如何创建和分配权限级别。

使用权限级别

权限级别是在网站范围内定义的权限命名集。WSS 内建了四个权限级别：Read（读取）、Contribute（参与讨论）、Design（设计）和 Full Access（完全访问）。如果需要在级别设置上更为精细，可以使用 WSS 对象模型或通过网站集所有者能够访问的标准 WSS 管理页，创建属于自己的自定义权限级别。

权限级别有时称为角色，在 WSS 对象模型中通常使用 SPRoleDefinition 对象表示这些权限级别。您可以使用 SPRoleAssignment 对象为外部用户或组分配权限级别。例如，此处我将内置的 Contribute 权限级别分配给登录名为 LITWAREINC\BrianC 的 Windows 用户：

复制代码

SPWeb site = SPContext.Current.Web;

SPRoleDefinition role = site.RoleDefinitions["Contribute"];

SPRoleAssignment roleAssignment;

roleAssignment = new SPRoleAssignment(@"LITWAREINC\BrianC",

"brianc@litwareinc.com",

"Brian Cox",

"Notes about Brian Cox");

roleAssignment.RoleDefinitionBindings.Add(role);

site.RoleAssignments.Add(roleAssignment);

使用这种方法，您不必将用户添加到某一 SPUser 集合中，因为在网站内首次为外部用户或组分配权限时 WSS 已自动完成这一操作。您刚才看到的代码会在“用户信息列表”中创建一个用户配置文件（如果原来不存在），并将该用户添加为当前网站的 Users 集合的成员。

WSS 组

WSS 安全模型不仅将外部安全主体表示为 SPUser 对象，而且还提供了 WSS 组，以方便网站集范围内的权限配置。例如，您可以在网站集中为诸如 Site Members（网站成员）、Content Manager（内容管理员）和 Site Administrators（站点管理员）的特定用户角色设计一系列 WSS 组。完成此项操作之后，您只需为 WSS 组分配权限级别即可配置网站的安全设置，而无需将权限级别直接分配给 SPUser 对象。

创建 WSS 组明显的好处是有助于消除添加或删除新的外部用户和组时重新配置权限的需要。您只需创建网站时配置权限，即可做到一劳永逸。之后，只需向 WSS 组中添加或从其中删除外部用户和组即可。WSS 组采用与 Active Directory 组完全相同的设计原则，二者的主要区别在于 WSS 组仅在单个网站集范围内定义和存在。

WSS 对象模型中将 WSS 组表示为 SPGroup 对象。SPWeb 对象公开两个 SPGroup 对象集合，分别为 Groups 和 SiteGroups。Groups 集合包括当前网站中所有已直接分配权限的 WSS 组，而 SiteGroups 集合则是 Groups 集合的超集，其中包括所有在当前网站集内创建的 WSS 组。

如果您希望创建一个新的 WSS 组，您应该调用 SiteGroups 集合公开的 Add 方法，然后在目标网站内为新的 WSS 组分配一个或多个权限级别。图 2 所示为新建一个名为 Site Members 的 WSS 组并在当前网站内为其分配内置 Contribute 权限级别的示例。

Figure 2 创建一个新的 WSS 组

复制代码

SPWeb site = SPContext.Current.Web;

SPUser currentUser = site.CurrentUser;

// create new group

site.SiteGroups.Add("Site Members", currentUser, currentUser,

"Site Group created at " + DateTime.Now.ToString());

// assign permission level to new group

SPGroup NewGroup = site.SiteGroups["Site Members"];

SPRoleAssignment roleAssignment = new SPRoleAssignment(NewGroup);

SPRoleDefinition permLevel = site.RoleDefinitions["Contribute"];

roleAssignment.RoleDefinitionBindings.Add(permLevel);

site.RoleAssignments.Add(roleAssignment);

新的 WSS 组创建完毕后，将外部用户和组添加为成员就变得轻而易举了。由一个 SPGroup 对象提供一个 AddUser 方法，该方法接受一个 SPUser 对象，然后您就可以添加外部用户和组了：

复制代码

SPWeb site = SPContext.Current.Web;

SPUser currentUser = site.CurrentUser;

SPGroup group = site.SiteGroups["Site Members"];

SPUser user1 = site.SiteUsers[@"LITWAREINC\BrianC"];

SPUser user2 = site.SiteUsers[@"LITWAREINC\AllFTE"];

group.AddUser(user1);

group.AddUser(user2);

标识、提升和模拟

WSS Web 应用程序的工作进程是通过 IIS 应用程序池进行控制的。Web 应用程序的工作进程标识可保证您对进程的关注，您可以通过 SharePoint 管理中心应用程序配置这些标识。您应根据域帐户（例如 LITWAREINC\SP_WorkerProcess）配置 Web 应用程序的工作进程标识，而不应根据本地帐户（例如 NETWORK SERVICE）进行配置。

请注意，Web 应用程序的工作进程标识必须是一个拥有特权的 Windows 帐户，该账户已配置了 SQL Server 权限，能够对一个或多个内容数据库进行读写操作。运行 SharePoint 管理中心网站的 Web 应用程序的工作进程标识必须具有更多特权，因为它需要拥有对场的配置数据库进行读写操作的权限。

当 Web 部件或自定义应用程序页的代码响应用户请求开始执行时，该代码不会以托管 Web 应用程序的工作进程标识执行。而是由 WSS 通过模拟将 Windows 安全上下文切换到其他 Windows 帐户。实际上，如果您查看 WSS Web 应用程序的 web.config 文件，会看到以下项：

复制代码

<system.web>

</system.web>

</configuration>

如果是为已使用 Windows 帐户进行身份验证的用户执行请求，则该请求会模拟当前用户的 Windows 标识。但是，同样的方法并不适用于 FBA 用户，因为 FBA 身份验证不会创建 Windows 安全令牌，而且也没有 Windows 标识。因此，使用 FBA 身份验证的用户的请求会模拟已经配置为匿名访问的 Windows 帐户的身份标识。IIS 中为此帐户默认分配的是 IUSER_MACHINENAME 帐户，但您可以（并且通常应该）重新配置此帐户以指向域帐户。

现在，让我们回过头来看一看更高级别的 WSS 安全编程。WSS 安全模型通常会强制要求开发人员对 Windows 标识和 WSS 用户标识加以区分。但是在一个请求中，如果当前 Windows 标识和当前 WSS 用户标识都指向同一 Windows 登录名时，则上述情况可能不太明显。而在使用 FBA 的情况下，事情就会变得更加复杂。例如，WSS 用户标识可能指向名为 Andrew 的 FBA 用户，而基本 Windows 标识则基于 IUSER_MACHINENAME 帐户。当您的代码尝试访问 WSS 对象时，WSS 会使用用户的 WSS 标识运行访问检查。而当您的代码尝试访问 WSS 之外的外部对象（例如 Windows 操作系统维护的文件）时，操作系统会使用 Windows 标识（代码正以此标识执行）运行访问检查。

有时候要执行代码，您需要使用比当前用户权限更高的权限。例如，我们可以假设这样一个情景：在处理一个仅拥有只读权限的用户的请求时，您的代码必须向一个列表写入数据。而默认情况下，您的代码要以与当前用户相同的权限来运行。这时，您可以调用 SPSecurity 类的 RunWithElevatedPrivileges 方法，提升代码的安全上下文。请注意，调用 RunWithElevatedPrivileges 将同时提升 WSS 用户标识和 Windows 标识。

现在想像这样一种情形：用户通过登录名 LITWAREINC\BrianC 使用 Windows 帐户进行身份验证。调用 RunWithElevatedPrivileges 会将 WSS 用户标识提升为 SHAREPOINT\System 帐户。SHAREPOINT\System 帐户内置于 WSS 运行库，在 WSS 授权模型中拥有完全的权限。调用 RunWithElevatedPrivileges 还将切换执行代码的 Windows 标识，从而该代码以当前 Web 应用程序的工作进程标识运行：

复制代码

// BEFORE ELEVATION

// WSS User identity = LITWAREINC\BrianC

// Windows identity = LITWAREINC\BrianC

SPSecurity.RunWithElevatedPrivileges(delegate() {

// AFTER ELEVATION

// WSS User identity = SHAREPOINT\System

// Windows identity = LITWAREINC\SP_WorkerProcess

});

在某些情景中，您可能会选择在尝试访问 Windows 文件系统或 SQL Server 数据库中的文件之前调用 RunWithElevatedPrivileges 方法，以便更改当前调用的 Windows 标识。另请注意，如果您从 Windows 标识切换到进程标识（例如 LITWAREINC\SP_WorkerProcess），则可以不必在 Active Directory 环境下对委托进行配置。当您的自定义 Web 部件能够使用 Windows 集成身份验证访问远程 SQL Server 数据库中的数据时，这项功能会非常有价值。

另外还会出现其他情景，您可能需要通过调用 RunWithElevatedPrivileges 方法将 WSS 用户标识提升为 SHAREPOINT\System，以便您的代码能够执行在当前用户权限下不允许的操作。一旦代码能够以 SHAREPOINT\System 身份运行，您就可以在 WSS 授权子系统中几乎随心所欲地执行任意操作。

调用 RunWithElevatedPrivileges 提升为 SHAREPOINT\System 帐户也有其相对棘手的一方面。例如，设想您调用 RunWithElevatedPrivileges，然后尝试通过 SPContext.Current 属性访问当前网站集或网站中的对象。您也许想不到代码会出错，但事实可能出乎您的意料：

复制代码

SPSecurity.RunWithElevatedPrivileges(delegate() {

SPSite siteCollection = SPContext.Current.Site;

// next line fails if current user is Contributor

string siteCollectionOwner = siteCollection.Owner;

});

为什么将 WSS 用户标识提升为 SHAREPOINT\System 之后本示例代码会执行失败？这与 SPSite 对象的创建时间有关。SPSite 对象及其子对象 SPWeb 的权限实际上并不依赖于当前 WSS 用户标识。而是依赖于创建 SPSite 对象时的 WSS 用户标识。在这里，由于可通过 SPContext.Current 进行访问的 SPSite 对象是在之前的请求中创建的，在该对象创建时，您的代码还无法切换其 WSS 用户标识。

因此，您需要使用一点技巧，在调用 RunWithElevatedPrivileges 并将 WSS 用户标识提升为 SHAREPOINT\System 之后，创建一个新的 SPSite 对象：

复制代码

SPSecurity.RunWithElevatedPrivileges(delegate() {

using (SPSite elevatedSiteCollection = new SPSite(this.Site.ID)) {

using (SPWeb elevatedSite =

elevatedSiteCollection.OpenWeb(this.Web.ID)) {

// access elevatedSiteCollection and

//elevatedSite as SHAREPOINT\System

}

});

这样就可以打开网站集及其中的网站，以便您的代码能以 SHAREPOINT\System 身份访问对象。

您可能还发现有必要模拟特定的 WSS 用户标识。这种方式在为事件处理程序或自定义工作流模板编写代码时（这种情况下代码默认以 SHAREPOINT\System 身份运行）非常常见。例如，您可能希望在创建新对象之前模拟特定 WSS 用户标识，以便 WSS 用户能被识别为新对象的所有者。

为了模拟 WSS 用户标识，您必须先创建一个 SPUserToken 对象。您可以使用 SPUser 对象的 UserToken 属性实现这一操作。创建好 SPUserToken 对象之后，您就可以使用该对象利用 SPSite 类构造函数的重载版本来创建新的 SPSite 对象。此方法如图 3 所示。

Figure 3 模拟 WSS 用户标识

复制代码

SPWeb siteCollection = SPContext.Current.Site;

SPWeb site = SPContext.Current.Web;

// get SPUser object and acquire token

SPUser targetUser = site.SiteUsers[@"LITWAREINC\BrianC"];

SPUserToken token = targetUser.UserToken;

// create new SPSite and SPWeb object to impersonate user

using (SPSite impersonatedSiteCollection =

new SPSite(siteCollection.ID, token)) {

using (SPWeb impersonatedSite =

impersonatedSiteCollection.OpenWeb(site.ID)) {

// WSS identity switched to impersonate BrianC

// Windows identity does not change

}

关于使用 WSS 用户模拟，我需要指出几点重要的注意事项。首先，模拟 WSS 用户与调用 RunWithElevatedPrivileges 不同，因为前者不会更改当前 Windows 标识。例如，如果在模拟 WSS 用户之前一个请求以 LITWAREINC\SP_WorkerProcess 的 Windows 标识身份运行，则代码将以同一 Windows 标识身份继续运行。WSS 用户模拟不会将当前 Windows 标识更改为被模拟用户的标识。

同样需要注意的是，代码要模拟另一个用户，必须在特权状态下运行。但在事件处理程序或自定义工作流模板中无需担心这一问题，因为在这类情况下代码默认以 SHAREPOINT\System 身份运行。但是，Web 部件或自定义应用程序页中的代码在其有能力模拟其他 WSS 用户标识之前可能需要调用 RunWithElevatedPrivileges。

安全对象

配置 WSS 安全性的真正优势在于安全对象（例如网站、列表和列表项）提供的灵活性。每个安全对象都可以包含一个“访问控制列表”(ACL)，这是一个二进制数据结构，WSS 在运行时会使用它来确定安全主体是否已被授予了访问权限。默认情况下，首要网站是唯一拥有 ACL 的安全对象。子对象（例如列表、列表项和子网站）都继承其父对象的 ACL，除非它们拒绝继承并提供一个自己拥有的唯一 ACL。

WSS 对象模型中包含名为 ISecurableObject 的接口，用于在 WSS 网站集中建立安全对象模型（参见图 4）。ISecurableObject 接口是通过 SPWeb 对象、SPList 对象和 SPItem 对象实现的，它为在运行时执行访问检查以及配置权限提供了基础。

图 4 ISecurableObject 接口 (单击该图像获得较大视图)

当您着手在网站集中配置权限时，理解到所有网站、列表和列表项一起组成了安全对象的单一层次结构这一点是十分重要的。默认情况下，只有首要网站包含一个唯一的 ACL，并对权限级别的分配进行了定义，规定用户需要获得哪种权限才能访问对象。所有子对象的权限都继承自首要网站。但是，您可以为安全对象提供一套属于它自己的唯一权限级别分配，从而更加精细地配置访问控制。例如，使用图 5 所示的代码，您可以创建一个新文档库，并使用一组唯一的权限对其进行配置。

Figure 5 配置一组唯一的权限

复制代码

SPWeb site = SPContext.Current.Web;

Guid listID = site.Lists.Add("Proposals",

"Library desc",

SPListTemplateType.DocumentLibrary);

SPDocumentLibrary doclib = (SPDocumentLibrary)site.Lists[ListID];

doclib.OnQuickLaunch = true;

doclib.BreakRoleInheritance(false);

SPUser AllFteGroup = Web.SiteUsers[@"LITWAREINC\AllFTE"];

SPRoleAssignment assignAllFteGroup = new SPRoleAssignment(AllFteGroup);

SPRoleDefinition roleDesign = this.Web.RoleDefinitions["Read"];

assignAllFteGroup.RoleDefinitionBindings.Add(roleDesign);

doclib.RoleAssignments.Add(assignAllFteGroup);

doclib.Update();

此示例代码通过调用 BreakRoleInheritance 取消了默认的对父对象的权限继承关系。如果您调用 BreakRoleInheritance 并传送一个 true 的参数值，安全对象最初会被配置一个与父对象 ACL 相同的副本 ACL。如果调用 BreakRoleInheritance 并传送一个 false 的参数值，则安全对象最初会被配置一个空的 ACL。也就是说，此文档库对于既不是所有者也不是网站管理员的用户不提供访问权限。

Windows SharePoint Services 3.0 新增了一项很受欢迎的安全增强功能，让您可以将权限的配置具体到项目级别或文档级别。您可以通过 WSS 对象模型实现这一点，因为 SPListItem 对象也实现了 ISecurableObject 接口。

图 6 中的代码在文档库中创建了一个新文档，然后使用了一组与其父文档库不同的唯一权限进行配置。请注意，这段代码使用了名为 WriteDocument 的工具方法，可接受 SPDocumentLibrary 引用和文件名。该方法的实现使用 Office Open XML 文件格式创建 Word 文档，然后将其写回到文档库。WriteDocument 方法返回一个 SPFile 引用，该引用随后可用于访问与文档相关的 SPListItem，这样您就可以取消继承关系并分配一组唯一的权限。

Figure 6 设置与其父对象不同的权限

复制代码

SPWeb site = SPContext.Current.Web;

Guid listID = site.Lists.Add("Proposals",

"Library desc",

SPListTemplateType.DocumentLibrary);

SPDocumentLibrary doclib = (SPDocumentLibrary)Web.Lists[ListID];

doclib.OnQuickLaunch = true;

doclib.Update();

SPFile doc1 = WriteDocument(doclib, "Adventure Works Merger.docx");

doc1.Item.BreakRoleInheritance(false);

SPGroup group = Web.Groups["Litware Contact Managers"];

SPRoleAssignment assignContribute = new SPRoleAssignment(group);

SPRoleDefinition roleContibute = this.Web.RoleDefinitions["Contribute"];

assignContribute.RoleDefinitionBindings.Add(roleContibute);

doc1.Item.RoleAssignments.Add(assignContribute);

doc1.Item.Update();

结束语

我知道今天的讨论稍微有些仓促，只是让您对 WSS 的安全模型有一个大致的了解。我主要向您介绍了 WSS 如何使用“用户信息列表”中的配置文件在网站集这一层上对外部安全主体进行跟踪，以及 WSS 如何使用 SPUser 对象在 WSS 对象模型中表示这些外部安全主体。此外我还演示了 WSS 如何支持 WSS 组，并介绍了一些用于提升特权和模拟 WSS 用户的编程技巧。在开发用于实际工作的应用程序时，这些技巧能够为您提供所需的灵活性和强大功能。

尽管 WSS 需要依靠基础组件系统来执行身份验证，但它确实能够在授权和访问控制方面发挥应有的作用。WSS 授权模型很大程度上基于一种被称为权限级别或角色的权限命名集。权限级别可以被分配给 SPUser 对象，但在实际应用中您通常应该选择将权限级别分配给 WSS 组。

请将您想向 Ted 询问的问题和提出的意见发送至 mmoffice@microsoft.com。 mmoffice@microsoft.com.

Ted Pattison 是一名作家、培训师兼 SharePoint 领域的 MVP，现居住在美国佛罗里达州的坦帕市。他还自己开办了公司 Ted Pattison Group (www.TedPattison.net)，为专业开发人员提供 SharePoint 高级培训。Ted 刚刚完成了《Inside Windows SharePoint Services 3.0》一书，该书由 Microsoft Press 出版。

本文链接

sharepoint2010的控制台程序，找不到位于<url>的应用程序

2010-06-16T03:03:00Z

当我在sharepoint2010下测试代码时，using (SPSite site = new SPSite("http://..."))时，出现错误提示：

找不到位于<url>的应用程序。

将开发环境的编译目标平台设置下就好了。

本文链接

Customizing the Rendering of a Custom SPField (copy from todd's blog)

2010-05-21T02:54:00Z

http://blogs.msdn.com/toddca/archive/2009/01/23/customizing-the-rendering-of-a-custom-spfield.aspx

I was recently asked by a customer how to use a PropertySchema field value within a RenderPatten's CAML to control how a field is rendered. The idea is to create a new instance of the field and have some method to control how that field will be rendered at the time the column is instantiated. Unfortunately field values from the PropertySchema are not available via a <Property Select='myValue'/> within a ReanderPattern's CAML and nor is it possible to call a custom getter off the SPField derived class of your custom SPField. In most cases when a field is rendered it is done so within native (non-managed) code so the getter on your .net assembly will not get called. The field schema stored in the DB is what gets read to help generate the rendered output. Fortunately this schema can be accessed by SPFIeld.SchemaXml. Adding properties or attributes to the root element of this XML will allow the RenderPattern CAML access.

So let's take a look at a sample. For my scenario I want URL field however I want to control how that field is rendered. By default a URL field just renders the URL without wrapping that URL in an <a> tag. In our example we want to create a true hyperlink so we are going to generate a RenderingPattern which will wrap an <a> tag around the field value. In addition we want the creator of the field to choose what happens when that link is selected by the user. That is, will the navigation happen within the same window or will the browser open the URL in a new window. I call these options "Self" and "New" respectively.

Now that we have our scenario let's take a look at what it will take to wire up the new field. First I need to define our field via fldTypes XML. Code 1 shows what this looks like. As you can see the Parent is "URL" because we want to use the same storage and rendering of the built-in URL however we are going to tweak it a bit. The FieldTypeClass will be outlined in Code 2. The PropertySchema field is used to collect the user's intent on how the URL will behave within the client's browser and finally we have RenderingPattern CAML which will control how the field will be rendered within the browser. Note I have a FieldSwitch on a Property called 'HowOpenUrl', this value will not be chosen from the PropertySchema's HowOpenUrl directly however once you take a look at Code 2 you will see how this is done. The reminder of the RenderPattern uses the FieldSwitch to determine how to render the URL. The default rendering is an <a> tag with the target set to _self so the URL will be navigated to within the same window.

Code 1 – fldtypes_sample.xml

<?xml version="1.0" encoding="utf-8" ?>

<Field Name="TypeName">ConfigurableURL</Field>

<Field Name="TypeDisplayName">Configurable URL</Field>

<Field Name="TypeShortDescription">Configurable URL</Field>

<Field Name="FieldTypeClass">SampleConfigurableField.ConfigurableUrlField, SampleConfigurableField, Version=1.0.0.0, Culture=neutral, PublicKeyToken=3de2414d286dff3d</Field>

</Field>

</Fields>

</PropertySchema>

<Expr>

</Expr>

</Case>

</Case>

</Default>

</FieldSwitch>

</RenderPattern>

</FieldType>

</FieldTypes>

After creating a Class Library project and adding the proper reference to Microsoft.SharePoint I added the following code to define my ConfigurableUrlField. This field derives from the SPFieldURL class which is important because we defined in Code 1 that our ParentType is "URL". Like all custom fields we need to create the two proper constructors which not only allow our type to be constructed but properly instantiates the base type. Next we need to override the OnAdded() and OnUpdated() methods which each get called whenever this field definition is added to a new site column or when the site column definition is updated, for example when someone wants to change from a rendering of this field from "Self" to "New". The magic all happens in ConfigureSchemaXml(), this is where we access the base.SchemaXml and update it with our custom property's value as configured by the user. This is the only chance we get to manipulate the schema before being stored in the DB and used to render the field. Note the name of the attribute being added/updated needs to match the name being used within the FieldSwitch: <Property Select='HowOpenUrl'/>

Code 2 – ConfigurableUrlField.cs

namespace SampleConfigurableField

{

using System;

using Microsoft.SharePoint;

using Microsoft.SharePoint.WebControls;

using System.Xml;

public class ConfigurableUrlField : SPFieldUrl

{

bool _updating = false;

public ConfigurableUrlField(SPFieldCollection fields, string fieldName)

: base(fields, fieldName) { }

public ConfigurableUrlField(SPFieldCollection fields, string typeName, string displayName)

: base(fields, typeName, displayName) { }

public override void OnUpdated()

{

//ConfigureSchemaXml() will cause the OnUpdated event to be raised,

//to keep out of a stack overflow condition we bail early when updating

if (_updating)

return;

_updating = true;

{

base.OnUpdated();

ConfigureSchemaXml();

}

_updating = false;

}

public override void OnAdded(SPAddFieldOptions op)

{

base.OnAdded(op);

ConfigureSchemaXml();

}

void ConfigureSchemaXml()

{

string howOpenUrl = (string)base.GetCustomProperty("HowOpenUrl");

howOpenUrl = AreStringsEqual("New", howOpenUrl) ? "New" : "Self";

XmlDocument doc = new XmlDocument();

doc.LoadXml(base.SchemaXml);

if (doc.FirstChild.Attributes["HowOpenUrl"] == null)

{

XmlAttribute attrib = doc.CreateAttribute("HowOpenUrl");

attrib.Value = howOpenUrl;

doc.FirstChild.Attributes.Append(attrib);

}

else

{

doc.FirstChild.Attributes["HowOpenUrl"].Value = howOpenUrl;

}

base.SchemaXml = doc.OuterXml;

}

private bool AreStringsEqual(string s1, string s2)

{

return (String.Compare(s1, s2, true) == 0);

}

public override BaseFieldControl FieldRenderingControl

{

get

{

BaseFieldControl fldControl = new UrlField();

fldControl.FieldName = InternalName;

return fldControl;

}

For completeness I have included the manifest.xml used for deployment of the solution. I will not go over that here since the concept is covered in so many other places.

Code 3 – manifest.xml

<?xml version="1.0" encoding="utf-8" ?>

<Solution xmlns="http://schemas.microsoft.com/sharepoint/"

SolutionId="733641DA-95D9-446E-812E-6070947171B2"

DeploymentServerType="WebFrontEnd"

ResetWebServer="TRUE">

</SafeControls>

</Assembly>

</Assemblies>

</TemplateFiles>

</Solution>

Once we have our solution added and deployed within our farm it is time to use the field. I created a test list and added a new column based on the Configurable URL field I just deployed. Note the open to set how the URL will open within the browser.

Now back at my list I create a new list item – note that we did not create a custom field control but rather are using the SPFieldUrl's field control for editing of this field.

Finally we can see the URL in action. Obviously an image does not do it justice but if I look at the HTML source I can find what actually got rendered:

<a target="_self" href="http://www.msn.com" href="http://www.msn.com">http://www.msn.com</a>

本文链接