Q：我在安装新版本的QuickPart，替换已有的旧版本时，总有问题，应该怎么办？
A：请到QuickPart项目网站，下载“How to Uninstall QuickPart”文档，然后按照文档中的说明，先从服务器上彻底删除旧版本QuickPart，然后再重新安装新版本QuickPart。
Q：我能修改QuickPart的源代码，添加自己想要的新功能吗？
A：请到QuickPart项目网站，下载“Source Code”包，然后修改源码自己编译即可。
Q：我下载了QuickPart源码项目，用Visual Studio打开后，会提示错误？
A：QuickPart 1.03版本的源码项目使用了Visual Studio 2008 + VSeWSS 1.3，请确认你使用了正确的Visual Studio版本，并安装了VSeWSS 1.3扩展包。
QuickPart 1.03下载页面
上周末，在SharePoint 2010 Day技术活动上，我做了一个纯演示的课程，演示了Visual Studio 2010中所包含的SharePoint 2010开发功能。
下载更高清晰度的WMV文件。
今天，Erucy和我将几个小工具发布到了codeplex上。
WPManager（Web部件管理器）
用于在SharePoint2007上部署、卸载Web部件，无需编写dwp/webpart描述文件，无需编写manifest，无需手动修改web.config，只需要打开生成的dll文件，选择部署位置，点击“部署”就可以一切搞定。支持dll、cab和wsp三种部署方式。同时支持部分Web部件的卸载功能，同时还有个彩蛋。
地址：http://wpmanager.codeplex.com
OSSEventManager（事件处理程序管理器）
可以方便的在一个列表上部署、挂载、卸载SharePoint 2007的列表条目事件处理程序。
地址：http://osseventmanager.codeplex.com
Friendly Query
使用类似T-SQL语句的形式进行SharePoint列表查询，无需任何CAML。之前写过一篇blog：点击这里
地址：http://fquery.codeplex.com/
清除已删除用户
如果使用自定义Membership Provider来实现SharePoint网站用户认证，从自定义用户数据源中删除了用户之后，还需要手工从SharePoint网站中删除对应的SharePoint用户。这个工具可以帮助管理员自动清除那些已从数据源中删除的用户。
地址：http://sptoolscn.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=38497
Office Web Applications可以让用户在浏览器里面，直接查看和编辑Word、Excel、PowerPoint和OneNote文档，而无需在客户端安装相应的Office程序。
在网站集功能管理中，激活“Office Web Apps”，就能在当前网站集使用Office Web Apps功能了：
Office Web Apps的使用非常简单，直接使用文档的操作菜单中的“在浏览器中查看”和“在浏览器中编辑”菜单项就可以了：
当然，由于浏览器的能力限制，不可能做到像Office客户端程序那样丰富的编辑功能：
能“插入”的项目也比较少：
但有些功能还做得像模像样：
这是编辑PowerPoint幻灯片的样子：
利用Office Web Apps播放幻灯片的效果相当不错，包括幻灯片中的动画效果，都基本能够原样的表现出来。
Office Web Apps另外一个值得一提的特性，就是它能支持多人同时在浏览器里面对一个文档进行编辑（但Word和PowerPoint文档在Beta2中不支持多人同时编辑，不知道正式版的情况如何）。
比如，一开始只有一位同志在浏览器中编辑这个Excel工作表，在右下角能看到“1 person editing”的提示信息：
这时，另外一位同志在浏览器中也打开了同一份文档开始编辑：
这时页面右下角会立即出现提示信息，告诉用户，有另外一位同志，也开始编辑这个工作表了：
点击后能看到当前编辑者的名单：
那么多人打开同一份文档编辑的时候，是如何反应别人的编辑情况呢？Office Web Apps会自动将每个人的修改信息，发送给其他编辑者，这样，在每个人的浏览器中，都能反应出所有编辑者的修改结果。
最后，Office Web Apps是否仅支持IE浏览器呢？答案当然是否定的。在上面的两人同时编辑文档的截图中，您应该能看出来，右边那位同志使用的，是FireFox浏览器。
更新（2009/12/08）：
1、对于多人同时编辑文档，支持情况如下：
Excel文档支持多人通过Office Web Apps同时编辑；
Word和PowerPoint文档支持多人通过Office客户端程序打开文档实现同时编辑；
OneNote文档支持多人通过Office Web Apps或通过Office客户端程序打开文档同时编辑。
2、Office Web Apps支持仅允许用户通过浏览器查看文档，而不允许用户下载文档。
在拿到SharePoint 2010 Beta2的安装文件之后，安装它整体而言并不太麻烦。博客园的wengnet写了两篇图文并茂的文章介绍SharePoint 2010的安装（这里和这里）。如果您在安装的时候遇到问题，下面是一些可能有帮助的信息：
1、安装序列号在这里。
2、动手安装之前最好仔细阅读这篇文章。里面包含了你需要下载的补丁、当与DC安装在一起时如何启用Office Web App等大量提示性信息。
3、这里有一篇非常完整的从头到尾安装SharePoint 2010的文章，全程有截图和说明。
4、如果在尝试安装一个虚拟机，可以参考这里，按照说明注册后下载一个指导的PDF文档。
5、这个版本毕竟还是测试版，不可能没有问题。如果遇到了安装和开发的问题，请参考这里。
6、如果在使用Forms Services时出现“StateServiceLocalizedException”异常，请参考这里。
花了一点时间，把微软发布的一份SharePoint 2010学习指南翻译成了中文。内容其实不是很多，就两页，主要是当前一些学习资料的链接。如果想开始学习SharePoint 2010，倒是一份不错的学习指引。
点击下载PDF文件
使用过Office 2007的同学一定知道，Office 2007引入了一种全新的界面模式：Ribbon。在SharePoint 2010中，界面风格也将使用类似的Ribbon界面。Ribbon界面所显示的菜单和选项，将随着用户所在的页面以及用户当前可以进行的操作，而动态的进行调整。
下图是使用“Team Site”模板所创建出来的一个SharePoint 2010网站的首页：
在页面的上方区域，就能够看到相关的两个Ribbon面板：
其中“Browse”是标准的浏览模式，而“Page”，则表示了这个Ribbon面板中将放置与当前正在浏览的页面有关的页面操作。如果我们点击“Page”面板，就能够看到：
在“Page”这个面板中，包含了“Edit”（编辑当前页面）、“Check Out”（将当前页面签出）、“Edit Properties”（修改当前页面的属性）等按钮。有一些按钮本身是包含了子菜单的，比如“Edit”按钮：
如果我们点击“Edit”按钮，开始编辑当前页面，可以看到页面上方的Ribbon区域所显示的面板，也会自动调整为相应的编辑工具：
在页面编辑状态之下，我们可以使用Ribbon中的“Save”按钮，来保存我们所进行的更改：
现在让我们打开一个列表，可以看到，列表视图也发生了很大的变化。用户的所有操作，同样全部被放置到了上方的Ribbon区域：
对于列表而言，Ribbon区域中所显示的“List Tools”中的“Items”和“List”，分别表示了与列表项和列表相关的操作。比如，当我们点击“List”时，就能看到各种与当前列表相关的操作出现在了Ribbon区域：
现在让我们尝试添加一个新的列表项，这时可以看到另外一个界面上的重大变化，“对话框”的出现：
在2007版本中，几乎所有的界面都是通过单独的页面来实现，当用户需要添加或编辑列表项时，都是转到相应的页面，完成操作后再跳转回来。SharePoint 2010的“对话框”界面，使用户的操作更简洁，也减少了页面之间的跳转。
对于列表项的编辑，同样适用了“对话框”界面。除此之外，为了方便用户同时对多个列表项进行操作，列表视图中在每个列表项前面都添加了一个复选框，通过使用这个复选框，我们能一次对多个选中的列表项进行操作。比如，同时删除多个列表项：
或是在文档库中同时签出多个文档：
SharePoint 2010的列表还新增了一种编辑模式：Inline Editing。只要在列表视图中启用Inline Editing，用户就能够直接在列表视图中点击列表项左侧的编辑图标，编辑当前列表项，然后再通过点击左侧的保存图标，快速完成列表项的编辑：
这个系列的文章，是为了帮助大家更好的了解SharePoint 2010。拥有SharePoint 2007的经验能够帮助您更容易的理解本系列的文章，但我会尽量使没有SharePoint 2007经验的读者也能不困难的进行阅读。
下图是一张SharePoint 2010基本架构图，它简要的描述出了SharePoint 2010的基本结构。
当我们说“SharePoint 2010”时，实际上是包含了SharePoint Foundation 2010和SharePoint Server 2010这两个产品。SharePoint Foundation在之前的版本中，被称为Windows SharePoint Services（WSS）。SharePoint Foundation是SharePoint Server的基础构件，SharePoint Server依赖于SharePoint Foundation。我们可以在系统中仅安装SharePoint Foundation，而不安装SharePoint Server（比如，由于价格的原因），但是如果我们直接安装SharePoint Server，则会默认的安装上SharePoint Foundation。
如果本文中没有明确的指出，那么SharePoint 2010默认包含了SharePoint Foundation 2010和SharePoint Server 2010。
SharePoint 2010完全基于x64架构，且不再包含x86版本。这也就决定了SharePoint 2010所要求的硬件和软件环境：
- 1. 服务器硬件必须支持x64；
- 2. SharePoint 2010服务器的操作系统必须使用Windows Server 2008 x64或Windows Server 2008 R2 x64；
- 3. SharePoint 2010服务器所使用的数据库必须是SQL Server 2005 SP2 x64或SQL Server 2008 x64。
如果您希望将现有的SharePoint 2007系统升级到SharePoint 2010，那么首先，必须将SharePoint 2007系统迁移至x64环境，包括硬件、操作系统和数据库，然后才能顺利的将SharePoint 2007升级到2010版本。
为了方便SharePoint开发人员，SharePoint 2010提供了一种方式，允许开发人员将其安装到64位的Windows Vista和Windows 7操作系统之中。这样，开发人员可以在自己安装了Windows Vista或Windows 7的开发环境中，使用Visual Studio 2010进行SharePoint应用程序开发。（后续文章将详细介绍如何在Windows Vista和Windows 7上安装SharePoint 2010。）
SharePoint是一个基于.NET/ASP.NET技术的Web应用平台。SharePoint 2010基于.NET Framework 3.5 SP1版本。没错，虽然SharePoint 2010的开发将主要使用Visual Studio 2010，但它使用并依赖于.NET 3.5 SP1，而并非.NET 4.0。
Office 2010（在本系列文章中，“Office 2010”指Office 2010系列的客户端软件，如Word、Excel、SharePoint Designer等）与SharePoint 2010有了更好的集成性。这体现在：
- 1、 SharePoint Designer 2010功能更丰富，比如，它内置了更强大的工作流设计器，并且可以通过Business Connectivity Services直接连接到数据库；
- 2、 在Visio 2010中，可以直接设计SharePoint 2010工作流，然后将设计好的流程导出至SharePoint Designer 2010的工作流设计器；
- 3、 Groove 2007变成了SharePoint Workspace 2010，它现在可以将SharePoint网站中的文档库和列表数据，同步到客户端之中，以实现离线访问，同时允许用户在本地编辑文档库和列表数据，然后同步到SharePoint网站中。
从北京时间昨天晚上开始，随着SharePoint Conference 2009开幕，有关SharePoint 2010的NDA就结束了。这也就是说，无论是MVP，还是参加了SharePoint 2010 TAP的用户，都可以开始自由的在博客、论坛上撰写或讨论有关SharePoint 2010的内容。
在SharePoint Conference 2009的网站首页上，已经可以收看到会议第一天早上的Keynote视频。另外还有一些不错的视频也被放在了SharePoint Conference 2009会议网站上，比如SharePoint 2010 Customer Excitement。
刚刚上线的SharePoint 2010 Developer Center上面已经有了不少有价值的内容，比如2010 SDK。如果您是一名SharePoint Application Developer，那么SharePoint 2010 Developer's Evaluation Guide是一定要看的。如果你是一名SharePoint Administrator，那么也可以阅读SharePoint 2010 IT Pro's Evaluation Guide。
SharePoint 2010的公开测试版将在11月份发布。
大约一年前，我曾经在blog上写过一篇文章，讲述了我对于SharePoint解决方案开发模型的一些想法，其中包括了SharePoint解决方案开发的方方面面，从开发团队，到开发环境的建立、物理与逻辑架构的设计、开发流程、信息架构、测试等等等等。这些主题我相信对于SharePoint开发人员、架构师、项目经理而言，都是非常有价值的。
既然直到现在，国内仍然没有任何SharePoint开发书籍（当然也包括我的《SharePoint 2007 开发入门指南》）讲述上面这些主题，所以决定开始在自己的blog上面，陆续就每个主题，撰写一些文章。希望这些文章能帮助到SharePoint技术社区。
每每涉及到比“具体”技术细节更高一层的架构、流程、方法论的东西，通常都很容易引起争议。这是很正常的现象。这些主题和具体的诸如C#语法、怎么做一个Web Part等等都不相同，因为这些主题根本就不会有一个标准答案。每个人心中都对如何设计一个架构、如何实施某个流程都有自己的想法，而环境与条件的不一致，更是使得所谓的“最佳实践”在很多场景中都不适用。所以，如果你对我撰写的文章中的某些内容不认可，没有关系，这些文章中的内容本来就不是“金科玉律”，甚至在你所处的场景中根本就是错误的。这些文章只代表我个人的意见（但其中肯定有不少想法，来自MSDN以及其他人所撰写的博客和文档），同时我也希望它们能成为交流的一个平台。如果你对文章中的内容有意见和想法，欢迎留言。高质量、有价值的留言，通常都能让后来的阅读者受益良多。
任何软件项目的实施，都必须从实施团队开始。所以，首先要讲述的主题，是如何建立一个SharePoint实施团队。
从本质上来说，实施一个SharePoint项目，与其他类型的软件项目，诸如ASP.NET、PHP，都不会有根本的差别。所以一个SharePoint实施团队的组成，也基本上和一个标准的Web项目实施团队相同。在下面的角色描述中，我基本上只会描述和SharePoint相关的部分，而其他通用的内容则会尽量省略。
项目经理
项目经理是整个项目的管理者。他负责指派任务、记录和跟踪进度、向老板们汇报...总之，项目经理的工作就是要保证整个项目处于正常状态，并能顺利完成。在小型团队中，项目经理有可能同时兼任业务分析人员。
业务分析人员
业务分析人员应当与客户充分交流，弄清楚客户的业务需求、流程等等信息（越详细越好）。业务分析人员与架构师一起工作，撰写出应用系统的功能规格说明书（也可能叫其他名字），不管我们叫这份文档什么名字，它都应当至少包含有：
1、整个项目要解决的问题、目标
示例：“ABC公司是一家卖汽车的企业，它总共有300名销售人员，销售人员希望通过一个“客户管理系统”对他们各自的客户进行管理。在这个系统中，销售人员能够查看自己负责的客户、每个客户的详细信息、每个客户的订单历史记录等信息。同时，销售人员还需要通过这个“客户管理系统”提交季度销售预测报告...”
2、针对用户使用场景的User Cases
这里的User Cases信息，应当详尽的描述出用户使用系统的每个具体场景，它将作为整个团队的一个“基础文档”，架构师和开发人员根据这些信息，才能知道程序最终要实现的效果。每个User Case里面都要包含用户几乎每个操作的描述和说明，以及每个主要界面的图示（使用Visio或其他工具绘制），也就是说，它不能含糊，而应该清晰、明确、有针对性。
示例：“User Case 15 - 销售人员Dashboard”
“销售人员在“客户管理系统”主页上点击“Dashboard”按钮（参考User Case 5），就能够打开自己的Dashboard...Dashboard会自动校验当前浏览用户的身份和权限，如果的Dashboard以两栏的方式来展现信息（参考图15-3），其中左栏自上而下会包含5个链接，分别是...销售人员点击了左栏的“历史订单数据”链接之后，页面将转向到“历史订单数据”页面（参考User Case 26）...中间的向右箭头是一个可以允许销售人员将右栏折叠起来的图标，在点击它之后...销售人员可以点击右上角的“返回”图标，以返回到“客户管理系统”主页...”
功能规格说明书不涉及具体的技术细节，不包含如何实现每个场景的技术说明，不包含系统的设计内容。我们可以这样想象，假设团队中突然来了一个陌生人，他希望能了解这个团队到底在做一个什么项目，这个项目是干嘛的，实现了什么功能，我们可以将这份功能规格说明书给他，而他确实可以从这份文档中了解到他希望了解的这些信息。
这份文档不能由业务分析人员一个人独自写成，而一定要有技术人员（以架构师为主）的共同参与。一方面，架构师的参与可以保证规格说明书中的内容，在技术上是可行且合理的，另一方面，也有助于架构师从业务角度了解系统，明白客户的需求。
我个人对功能规格说明书的重要性非常推崇。在项目中，可能我们不会撰写详细的设计文档，可能我们不会撰写详细的部署文档，但一份详细的功能规格说明书确是不可缺少的。它的重要性体现在：
1、让团队中的所有人都明白我们要构建的是一个什么东西。如果没有这样的一份清晰的功能规格说明书，就不能保证团队的所有人都一致了解团队的目标。如果没有它，业务分析人员会根据客户的描述，在自己的大脑中想象出系统应该有的样子，然后口述给开发人员，并假设开发人员完全明白了自己大脑中的想法，而开发人员则会根据自己从业务分析人员那里听到的，在自己的大脑中又试图去想象系统做出来应该是什么样子的，并假设这就是业务分析人员想要的样子...总之，每个人都会根据自己的“想象”，去猜测别人的意图。而最后当开发人员把最好的东西给业务分析人员演示的时候，通常是业务分析人员大吃一惊：“我kao，怎么是这个样子？这根本和我告诉你的是完全不一样的东东...”而开发人员则会辩解：“胡说，这分明就是我根据你告诉我的要求做出来的...”
2、我们有了一个可以和客户讨论的东西。这份文档可以尽早的交给客户审阅，客户可以根据这份文档，了解到系统做出来会是什么样子，如果不满意，客户也可以及早的和开发团队进行沟通：“嗯，不对，在这个地方，其实我们更希望看到一个选择框，而不是用户自己填...”
3、它是业务分析人员与开发人员之间的一份“合同”。业务分析人员可以充分的假定，开发人员最后交付的，就是功能规格文档中所描述的样子，而开发人员也可以充分的假定，业务分析人员需要的，也是文档中所描述的样子。
值得一提的是，功能规格说明书并不会（也不应该）限制开发人员的“自由”。它仅仅包含对业务场景、系统功能的详细描述，但是不会写上应该如何实现。它肯定不会包含诸如“在这里，我们要创建XYZ类和ZYX类，前者用于从数据库中查询QWE表...”，也不会包含诸如“我们将使用3层结构，并由5个主要模块来构成整个系统框架...”之类的信息。如何设计、如何实现，应该由架构师和开发人员讨论并确定，而没有必要写到功能规格说明书里面。
架构师
架构师首先应当与业务分析人员一起撰写功能规格说明书，以保证其中所包含的内容在技术上的可行性，这同时也能保证架构师非常了解整个系统的业务需求。其次，架构师应该以功能规格说明书为基础，为整个系统设计物理架构和逻辑架构，将整个系统合理的拆分成各个更小的模块与组件，并将模块与组件的开发任务分配给开发人员。架构师还要与开发人员非常紧密的一起工作，与每位开发人员讨论并确定每个模块的实现方式。架构师应当是技术负责人，确保整个项目在技术上畅通无阻。
系统物理架构也就是整个系统在物理上、网络上的拓扑模型。整个系统需要多少台服务器？每个服务器是什么角色？网络设置应该是怎样的？是否需要DMZ区域中也要部署一台SharePoint服务器（如果用户需要从Internet访问的话）？或是使用DMZ中ISA Server来进行Internet发布？这些设计都是属于系统物理架构上的设计。
系统逻辑架构是从逻辑上描述整个系统的结构。整个系统有几个SharePoint服务器场？有几个SharePoint Web Application？几个Site Collection？每个Site Collection是做什么的？会包含哪些内容？为哪个群体的用户服务？各个不同区域的安全模型是怎样的？这些设计就属于系统逻辑架构设计。
子模块与组件的拆分也是架构师需要承担的工作。如何将整个系统拆分成更小的模块与组件？按何种方式与原则进行拆分？比如，是按照传统的N层架构来拆分（将“数据层”模块交给一个开发人员做，将“业务逻辑层”模块交给一个开发人员做，将“UI层”模块交给一个开发人员做...）？还是按照业务功能来拆分（将“客户数据维护”功能模块交给一个开发人员做，将“订单历史数据查询”功能模块交给一个开发人员做，而每个功能模块实际包含了实现那个功能所需的所有从数据到业务逻辑到Web Part展现相关的所有部分...）？不同的拆分方式，就决定了如何为开发人员分配工作，并会影响到后续一系列的诸如集成测试之类的环节。
开发人员
终于，开发人员登场了。开发人员的工作就是理解自己所负责的模块与组件相关的业务需求，仔细阅读（并可能参与编写）功能规格说明书，与架构师紧密合作，将功能实现出来。
作为一个SharePoint开发人员，是非常有挑战性的。需要学习和掌握的知识点非常的多，才可能从容不迫的将手头的开发任务完成。拥有强有力的SharePoint开发人员，是整个项目能否顺利完成的关键因素。
SharePoint开发人员需要掌握的知识包括：SharePoint、ASP.NET、XML、Windows Workflow Foundation、JavaScript、InfoPath，未来还可能需要加上Windows Communication Foundation、LINQ、Silverlight、PowerShell...
测试人员
当我说到“测试人员”时，实际上包含了两类人。一类是对开发人员写出的代码进行测试的人，这种人可能由开发人员（通过贯彻Unit Test流程）兼任，第二类则是在SharePoint解决方案开发过程中，进行集成测试和最终环境测试的人，这种人也可以由某位开发人员兼任。
集成测试是指，在一个独立的集成环境中（通常是一个“干净的”SharePoint服务器场），定期将所有开发人员交付的模块与组件部署进来，并对它们的功能以及它们相互之间的关联进行测试。一个集成测试环境对于SharePoint开发而言是必不可少的。
网络与系统管理员
网络与系统管理员是那些负责建立和管理开发团队所使用的各种环境的人。这些环境包括位于每个开发工作站上的开发环境，进行集成测试的集成服务器环境，进行部署前测试的最终测试环境，以及生产环境。网络和系统管理员负责将开发人员交付的模块与组件，部署到各个环境中（比如测试环境、生产环境）。将有了环境管理员，开发人员也可以快速的得到一个标准的SharePoint开发环境。网络与系统管理员可以由某位非常熟悉SharePoint管理的开发人员兼任。
当然，根据各个项目需求的不同，团队中还可能有其他的角色存在，比如美工、文档编撰人员等。这些我们就不再一一详述了。本系列的下一篇文章，将讲述SharePoint解决方案开发中所涉及到的各个环境。
这两天在忙着修饰自己部门的Team Site，老板提出了一个期望，想在Team Site首页上放一个Timeline，这样部门有什么新的事件、日程，都能在Timeline上展现出来。这件事本身并非特别麻烦，但是我们的Team Site是放在公司Hosting的SharePoint系统之中（公司提供SharePoint Hosting服务，每个人/部门可以根据自由要求，以自助的方式申请Site来使用），而公司Hosting的系统，是不允许各个网站的所有者使用任何Server Code（服务器端代码）的。从IT管理的角度来说，这也是非常合理的，但这的确大大限制了各个网站的使用者对各自的网站进行定制的能力。换句话说，我能使用的工具，只有SharePoint内置的各个Web Part，以及SharePoint Designer。（在SharePoint 2010中，提供了一个新的特性：Sandboxed Solution，来解决这个问题，各个网站集的管理员可以通过upload的方式，部署功能与权限受限的Solution Package到网站集之中，但又不会影响其他网站集和整个服务器场的安全与稳定。）
在经过一番考虑之后，我确认在不允许服务器端代码的前提下，是可以通过JavaScript和HTML的能力，实现一个Timeline的。下面这张图是最终实现后的效果：
这个Timeline分成了3栏，从上至下分别是日、周、月视图，用户可以使用鼠标对每个栏进行滑动操作，以查看之前和之后日期的各个事件。Timeline中的事件，来自于网站中一个日历类别列表中的数据，这样网站使用者只用在列表中添加新的事件，Timeline中就会自动显示出来：
实现的关键是两点：
1、使用JS从网站列表中，获取到所需的列表项数据；
2、使用JS和HTML，在SharePoint页面上渲染出Timeline。
首先，我在网站中使用“日历”列表模板，创建了一个新列表。由于在Timeline控件上，我只希望能够显示当天前后30天之内发生的事件，为了更容易的取到当天前后30天的事件列表项，我在列表中创建了一个新的视图，在这个视图中只显示事件开始时间是位于当天前后30天的事件。为什么创建这样的一个视图就能方便我们在页面上用JS获取想要的数据，看到后面大家就明白了。
为了让这个新视图能进行查询过滤，我为列表创建了两个新的计算类型字段，"30DaysBeforeStartTime"和"30DaysAfterStartTime"，下图显示了"30DaysBeforeStartTime"的定义方法：
"30DaysAfterStartTime"的定义方法也类似，只是公式变成了"=[Start Time]+30"。
很多人都不知道在计算字段中，应该如何使用公式。在这个页面上，有能够使用的所有公式和函数的说明，这里还有一些最常用的公式的示范。
有了这两个字段，我们就可以为新的视图来设置过滤条件了，通过下图中的条件，就能过滤出当天的前后30天之类的事件：
有了这个新的视图之后，我们就能保证，我们需要在Timeline中显示的数据，肯定都会被这个视图所包含。接下来我们进入到JS阶段...
如果要用JS获取SharePoint网站中的数据，比较靠谱的方法是用JS调用SharePoint的Web Services接口。SharePoint提供了不少Web Services接口，让我们可以在各种平台和语言中调用，其中就包括运行在页面上的JS。我们需要的是能够从列表中获取数据的Web Services接口，这个接口位于Lists Web Service里面，它提供了一个GetListItems()方法，让我们拿到列表项数据。其中，GetListItems()方法的第二个参数："viewName"，就可以让我们指定列表的一个视图，作为取数据的筛选条件。当然，我们也可以使用GetListItems()方法后面的参数来重新指定筛选条件，但是通过列表视图来制定筛选条件，要简单很多，而且修改起来也容易得多。
如何在JS中调用Web Services的方法在网络上能找到很多很多的文章，我就不再重复了。但我要推荐一个不错的JS库，使用这个JS库，可以免去手工构建SOAP包的麻烦，而且使用也相当的简捷。它包含许多的.js文件，将这些.js文件上载到网站的某个文档库中即可（实际上，并不一定需要复制所有的.js文件，比如，对于我的要求，我只用复制"SPAPI_Core.js"、"SPAPI_Types.js"和"SPAPI_Lists.js"即可）。我将所有这些乱七八糟的文件都放在一个名叫"SupportingFiles"的文档库中：
然后，用SharePoint Designer打开网站的母版页文件（默认是"default.master"），添加上对这几个.js文件的引用（图片上显示出还添加了对"http://simile.mit.edu/timeline/api/timeline-api.js"的引用，这个东东下面会讲到）：
使用上面所介绍的那个JS库，下面所示的代码就可以让我从一个列表中，将列表项取出来：
function getCalendarListItems()
{
var lists = new SPAPI_Lists("网站URL");
var items = lists.getListItems(
"Timeline", // 要获取数据的列表的显示名称
"{14CB7B04-46AA-421C-B6B2-C5FBEEBA9F5B}", // 视图的GUID，注意两边要加上大括号
"", // 查询条件
"", // 要返回的字段
100, // 要返回的数据的最大行数
"", // 查询选项
null // 网站的GUID，null表示使用上面的SPAPI_Lists构造函数里面的网站URL所对应的网站
);
if (items.status == 200)
{
var rows = items.responseXML.getElementsByTagName("z:row");
return rows; // 如果获取数据成功，将所有数据放在一个数组中，然后返回
}
else
{
return null;
}
}
通过JS拿到所需的日历事件数据之后，接下来，就是如何在页面上用HTML+JS渲染出一个Timeline。作为一个典型的ELC（Exist Library Caller），我首先想到的是到网上找找是否已经有人做过类似的东东，果然，在Google Code上就被我找到了一个，嘿嘿嘿...
在这个名为SIMILE Widgets的工具集中，包含了一个用JS实现的Timeline。经过在文档中一阵乱翻，下面的JS代码就能够帮我实现想要的效果（第一行不是JS代码，而是JS代码里面会使用的一个div元素，Timeline就是通过它显示出来）：
<div id="my-timeline" style="height: 120px; border: 1px solid #aaa; font-size: 9pt"></div>
var resizeTimerID = null;
function onResize() {
if (resizeTimerID == null) {
resizeTimerID = window.setTimeout(function() {
resizeTimerID = null;
tl.layout();
}, 500);
}
}
window.onresize = onResize;
function formatDateString(originDateStr)
{
var yearStr = originDateStr.substr(0, 4);
var monthStr = originDateStr.substr(5, 2);
var dayStr = originDateStr.substr(8, 2);
return monthStr + "/" + dayStr + "/" + yearStr + " " + originDateStr.substr(11);
}
function createTimeLineAndEvents()
{
var items = getCalendarListItems();
if (items == null)
{
alert("cannot got items from list.");
return;
}
var eventSource = new Timeline.DefaultEventSource();
for (var i = 0; i < items.length; ++i)
{
var ows_EventDate = formatDateString(items[i].getAttribute("ows_EventDate"));
var ows_EndDate = formatDateString(items[i].getAttribute("ows_EndDate"));
var ows_Title = items[i].getAttribute("ows_Title");
var ows_Location = items[i].getAttribute("ows_Location");
var eventDate = new Date(ows_EventDate);
var endDate = new Date(ows_EndDate);
var event = new Timeline.DefaultEventSource.Event(
eventDate, //start
endDate , //end
eventDate, //latestStart
endDate , //earliestEnd
false, //instant
ows_Title, //text
ows_Location //description
);
eventSource.add(event);
}
var bandInfos = [
Timeline.createBandInfo({
trackGap: 0.2,
width: "60%",
intervalUnit: Timeline.DateTime.DAY,
intervalPixels: 100,
timeZone : 8,
eventSource: eventSource
}),
Timeline.createBandInfo({
showEventText: false,
trackHeight: 0.5,
trackGap: 0.2,
width: "25%",
intervalUnit: Timeline.DateTime.WEEK,
intervalPixels: 150,
timeZone : 8,
eventSource: eventSource
}),
Timeline.createBandInfo({
showEventText: false,
trackHeight: 0.5,
trackGap: 0.2,
width: "15%",
intervalUnit: Timeline.DateTime.MONTH,
intervalPixels: 400,
timeZone : 8,
eventSource: eventSource
})
];
bandInfos[1].syncWith = 0;
bandInfos[2].highlight = true;
bandInfos[2].syncWith = 1;
var timeLine = Timeline.create(document.getElementById("my-timeline"), bandInfos);
}
_spBodyOnLoadFunctionNames.push("createTimeLineAndEvents");
唉，实在是有点长，本来不想全部贴出来，可想到也许有人要用的话，所以就...另外，别忘了在母版页里面，添加对"http://simile.mit.edu/timeline/api/timeline-api.js"的引用（如上面的截图所示）。
把上面的这些JS代码（以及一个"div"标签）都放到一个单独的.htm文件中，然后在想要显示Timeline的页面上放一个内容编辑Web部件。通过设置内容编辑Web部件的属性，告诉Web部件从那个.htm文件中去拿要显示出来的HTML源码（这种方式能让我们直接使用SharePoint Designer编辑那个.htm文件中的HTML和JS源码，而不必使用内容编辑Web部件内置的那个笨拙编辑器）：
OK，完成。另外提一下，在SharePoint 2010中提供了专门的Client OM，它直接支持使用ECMAScript（标准名词解释：ECMAScript是一种由Ecma国际（前身为欧洲计算机制造商协会）通过ECMA-262标准化的脚本程序设计语言。这种语言在万维网上应用广泛，它往往被称为JavaScript或JScript，但实际上后两者是ECMA-262标准的实现和扩展。）来访问SharePoint。
本书的中文版并没有附带配套CD，如果你需要第25、26章的代码，可以通过下面的链接下载原书的配套CD（由于在版权方面的考虑，其中删除了部分内容）。
今天，微软“半公开”发布了SharePoint 2010 Technical Preview。这是第一个对外发布的SharePoint 2010测试版本，它将提供给TAP（技术预览计划）参与者和MVP等少数群体。如果您是上面所列出的群体中的一员，那么恭喜您，您应该能直接拿到SharePoint 2010 Technical Preview相关的安装文件、文档和其他资料。如果不是，那么请继续往下阅读…
SharePoint 2010相比2007，从我的感觉来说，并没有“革命性”的突破，但在各个方面都有不少增强和改进。Office Web Application肯定是一大亮点。通过SharePoint 2010，用户可以直接在浏览器中查看和编辑Word、Excel、PowerPoint文档。当然，在大家所关注的开发支持方面，也有了相当大的改进。Visual Studio 2010中将直接内置SharePoint项目模板。如果您现在正在开发SharePoint 2007的项目，那么建议使用VSeWSS 1.3，微软有计划发布将VSeWSS 1.3项目升级到2010项目的工具。
在sharepoint.microsoft.com网站上，已经开始添加SharePoint 2010的内容，其中比较有用的包括：
■ SharePoint 2010 Overview视频
■ SharePoint 2010 for Developer视频
■ SharePoint 2010 for IT Pro视频
学习SharePoint 2010最好的方法，可能就是参加今年10月份在拉斯维加斯举行的SharePoint Conference 2009（简称SPC09），时间为10月19-22日。在SPC09中，将包含大量的有关SharePoint 2010的技术讲座。在参加完SPC09之后（10月23日），您还选择可以参加两个额外的各为期一整天的技术培训讲座：
■ SharePoint 2010 Developer Deep Dive：由Andrew Connell和Ted Pattison主讲
■ SharePoint Server 2010 Installation and Upgrade Workshop：由Todd Klindt和Shane Young主讲
当然，如果您没法参加SPC09，也可以follow它的twitter：twitter.com/SPConf。
在微软download网站上，可以下载一份有关SharePoint 2010的开发文档。里面包含了一个关于如何定制SharePoint 2010 Ribbon界面的白皮书，和一个没太多用处的chm文件。
最后是一点安慰：在今年的迟些时候，微软将发布SharePoint 2010的公开测试版本。SharePoint 2010的正式发布日期计划是在2010年上半年。
最近正好有个朋友问这个方面的问题，如何规划一个SharePoint系统的磁盘容量？如果不能在前期做系统规划（Planning）的时候，确定好所需的磁盘容量，那么就很可能遇到系统上线3个月之后，发现服务器磁盘不够用的尴尬情况发生。
在微软TechNet网站上，有一些相关的文档和白皮书，比如《Capacity Planning and Sizing for Microsoft SharePoint Products and Technologies》。但是如果你懒得阅读白皮书，那么我可以给出一些简要的参数，根据这些参数，你可以快速的估算出一个SharePoint系统所需要的大致磁盘容量。
1、首先，你需要估算出整个系统中将要存放的内容的总容量。如果整个系统的总容量会随着系统的运行而不断增加（很多时候确实如此），那么你就想想你希望整个系统在上线后多长时间之内不想再进行磁盘容量上的升级，然后估算出这段时间之内，系统所存放的内容的总容量。
比如，每个月，所有用户会上传大概10GB文档到SharePoint服务器上。如果你希望SharePoint系统在未来两年之内，不用考虑容量升级的问题，那么这两年内，SharePoint系统中将存放总共240GB的文档。
由于SharePoint 2007文档管理会有“版本控制”和“回收站”的功能，所以在你估算的时候，不要忘记估算这两个功能将要占用的磁盘容量。
比如，在整个系统中，如果你估算大概会有5%的文件会存放到启用了版本控制功能的文档库中（提示：通常，并非所有文件都会需要版本控制的功能，很多文件都是一次性完成，或是无需保留历史版本的，对于这个文件所在的文档库，应该谨慎的使用版本控制功能），并且通过文档库的设置，限制了最多只保留10个主要版本，每个主要版本最多只保留5个次要版本（提示：对于启用了文档版本的文档库，同样需要设置好最多的主要版本的次要版本，避免版本数量无谓的增加太多），那么对于上面算出的240GB文档，你就需要还要加上240GB * 5% * 10 * 5 = 600GB的容量。
这样，我们计算出来的总容量空间将是：240GB + 600 GB = 840GB。
2、由于SharePoint会将所有的网站内容都存储到SQL Server数据库中，对于整个系统的数据库，你要准备所有内容总容量再乘上1.2-1.5倍的空间，给到SQL Server数据库。
比如，对于在第一个步骤里面计算出来的内容总容量840GB，我们就要给SQL Server数据库准备840GB * 1.5 = 1.3TB的磁盘空间。
3、由于SharePoint里面的索引服务（Index Services）会为所有的内容创建索引文件，所以你还需要注意为索引文件准备足够的磁盘空间。索引文件会占用的磁盘空间，可以按照(内容总容量 * (5-12%)) * 3倍这个公式进行计算。
对于5-12%这个比例，需要按照SharePonit中所存储的内容类型来进行适当的调整。例如，对于文档类型的内容（.doc、.docx、.xls、.xlsx、.pdf等），索引文件所占用空间的比例肯定会要比图片文件要高。如果你的SharePoint系统中主要是存放文档类别的内容，那么你就要将这个比例适当的加大，也就是更接近12%。
比如，对于840GB的内容，如果这些只有一部分是文档类型，那么我们要为索引文件准备840GB * 8% * 3 = 200GB的空间。
注意，如果在你的SharePoint服务器场中，索引服务是运行在一台单独的索引服务器（Index Server）上，那么就要在索引服务器上准备这么大的磁盘空间。
4、如果在SharePoint服务器场中，查询服务（Query Services）不是与索引服务运行在同一台服务器上，由于SharePoint会自动将索引文件从索引服务器上复制到运行查询服务的服务器上，所以在所有运行了查询服务的服务器上，同样需要准备足够的磁盘空间，留给索引文件。要准备的磁盘空间容量，计算方法与索引文件的容量相同。
5、最后，为了防止在估算的时候过于乐观，而且你也有足够的预算，那么不妨将上面的所有计算结果再乘上1.5 - 3倍（倍数可以按照您手里的预算来决定，呵呵）。比如，为SQL Server数据库准备2TB的磁盘空间，为索引文件准备300GB的磁盘空间。
最后，介绍两个SharePoint容量规划工具。第一个是微软的SharePoint Capacity Planning Tool，这个工具依赖于System Center Capacity Planner 2007。根据我的使用经验，个人认为这个工具过于花哨，实用价值不太高。:)
第二个工具是HP ProLiant Sizer for Microsoft Office SharePoint Server 2007，它是HP公司发布的一个工具。我对此工具没有什么使用经验。
第6讲：SharePoint开发 - 模式与重构（涂曙光）
SharePoint Designer 2007变成了一个免费的产品。
中文版下载
在SharePoint 2007的列表中，可以通过列表设置直接启用项目级权限控制，使得只有每个列表项的作者能查看和编辑自己的项目。但是，文档库是没有这个功能的。最近有好几次被人为到这个问题，所以写了一个东东，安装到SharePoint 2007中，就可以为文档库启用这个功能了。
我将解决方案安装包和源代码都放到了spdoclibitemsecurity.codeplex.com上面，你可以直接到这个项目网站上下载安装包和源代码。
安装方法：
1. 在SharePoint 2007服务器上解压开安装包，然后执行里面的"install.bat"，进行安装和部署。
2. 在需要启用这个功能的网站，打开"网站设置"，然后进入"网站功能"，然后激活"文档库项目级权限"功能即可。
SharePoint网站默认是使用Active Directory集成认证，但如果是用于Internet场景，那么由于难以为访问用户建立AD帐号，解决方法通常是将SharePoint网站配置成使用Forms认证，在一个自定义的数据源（比如SQL数据库或其他的什么地方）中存储这些用户的凭证信息。
但有时候我们会遇到另外一种场景，那就是访问用户确实都在AD中有对应的帐号，但用户就是不习惯使用内置的那个Windows登录窗口，来输入自己的用户名和密码。这个时候，我们可以让SharePoint网站仍然使用AD认证，但是用户登录的时候，使用表单的方式，在页面上输入自己的AD帐号和密码，然后登录。下面的Video展示了完整的配置过程，以及如何做一个定制的登录界面。
第一部分：
<![CDATA[<a href="http://video.msn.com/?mkt=uv-en-us&tab=m555&playlist=videoByUuids:uuids:dec9f8b5-e1b5-435f-a303-5e2910cf4919&showPlaylist=true&from=IV2_en-us_videoguide_player&fg=gtlv2" target="_new" title="AD Auentication with Forms-Style Login in SharePoint">Video: AD Auentication with Forms-Style Login in SharePoint</a>]]>
第二部分：
<![CDATA[<a href="http://video.msn.com/?mkt=uv-en-us&tab=m555&playlist=videoByUuids:uuids:031b1794-cb9f-40fa-83b3-44189810d9a2&showPlaylist=true&from=IV2_en-us_videoguide_player&fg=gtlv2" target="_new" title="AD Authentication with Forms-Style Login in SharePoint (Part 2)">Video: AD Authentication with Forms-Style Login in SharePoint (Part 2)</a>]]>
Video中用到的配置信息：
(1)要添加到内容Web应用程序的web.config中的配置信息(粗体表示要添加的)
<configuration>
<connectionStrings>
<add name="ADConnectionString" connectionString="LDAP://moss070810.contoso.msft/CN=Users,DC=contoso,DC=msft" />
</connectionStrings>
<system.web>
<membership defaultProvider="ADMembership">
<providers>
<clear />
<add name="ADMembership" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="ADConnectionString" connectionUsername="contoso\Administrator" connectionPassword="pass@word1" attributeMapUsername="sAMAccountName" />
</providers>
</membership>
</system.web>
</configuration>
(2)要添加到管理中心Web应用程序的web.config中的配置信息(粗体表示要添加的)
<configuration>
<connectionStrings>
<add name="ADConnectionString" connectionString="LDAP://moss070810.contoso.msft/CN=Users,DC=contoso,DC=msft" />
</connectionStrings>
<system.web>
<membership>
<providers>
<add name="ADMembership" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="ADConnectionString" connectionUsername="contoso\Administrator" connectionPassword="pass@word1" attributeMapUsername="sAMAccountName" />
</providers>
</membership>
</system.web>
</configuration>
附注：
(1) 如果你对SharePoint 2007中的自定义用户验证没有太多概念，可以参考我以前写过的一篇文章：《在SharePoint Server 2007中创建定制的用户管理模块》。
(2) 由于对录制Video没太多经验，导致Video声音偏小，下次一定注意。
今天偶然发现，WSPBuilder在中文版本的Visual Studio上面无法正常工作（以前一直使用英文版VS，所以没发现有这种问题），在使用"Build WSP"指令时，会提示"值不在预期的范围内"。到WSPBuilder的项目网站找了一下，发现已经有使用法文版Visual Studio的用户，提出过这个Bug了。我从项目网站上找到源代码，修改了一下，让它可以兼容非英文版本的Visual Studio了。如果你习惯了使用中文Visual Studio，可以到这里下载我上传到页面上的附件"WSPTools.VisualStudio.VSAddIn.zip"。下载后，使用压缩包里面的"WSPTools.VisualStudio.VSAddIn.dll"，替换GAC里面的同名文件就可以了。
---------- 不低俗的分隔线 --------------
今天在InfoQ上看到了一篇不错的文章，是几个"大人物"关于Unit Test和TDD的争论，感兴趣的可以看看。
在这个月上海举行的.NET技术大会上，我将奉献一节名为《基于SharePoint的Web应用开发模型》的课程。由于大会的定位是“面向企业级.NET开发深度应用”，我相信大家想听的一定不是单纯的介绍SharePoint Server，或是怎么做一个Web Part。思来想去，终于定下了《基于SharePoint的Web应用开发模型》这个题目。我希望能在有限的时间内，和大家探讨如何利用SharePoint这个Web开发平台，如何组织一个团队，开发一个大中型的Web应用。内容将包括如何组建团队、如何构建团队开发环境、如何分工、如何有效的利用SharePoint提供的Solution框架来组织我们的项目内容、如何测试（单元测试、集成测试）。当然，除了这些稍微有些"High-Level"的内容，我还希望能探讨，作为一个SharePoint Developer，我们可以对SharePoint的哪些部分下手，如何下手，如何让自己的定制内容（页面、代码、流程）能真正“融合”到SharePoint平台里面，而不是只把SharePoint当作一个大类库和存储库。坏消息是，似乎有太多内容要讲，而每个主题都似乎能讲上很长时间，而好消息是，课程将有70分钟的长度，如果没有记错的话，这已经比TechED的课程长度要长了。
See you in Shanghai !
(2009-2-21 更新：从这里下载此课程的PPT)
Composite Web Application Block是Web Client Software Factory中一个用来开发Web应用的框架，它能帮助程序员更方便的使用MVP模式。关于CWAB的更多信息，请参考这里。
当我们开发SharePoint界面的时候，比如，创建一个Web Part，如果你希望使用MVP模式，是可以引入CWAB的。在这个文档中解释了如何在SharePoint中使用CWAB，但文档里面的一些步骤，其实不一定是最好的。比如，文档中告诉你，将各个程序集放到Web Application的/bin目录中，但我的建议是仍然将它们部署到GAC里面，这样，你就不需要更改Web Application的web.config中的<trust>节点，将代码的默认信任等级提高了。
嗯，总之，我们可以使用CWAB来方便的基于MVP模式来开发Web Part，比如下图所示的项目结构：
上图中的“KBSample.SiteUser.Module”是CWAB中的一个Module项目，包含了与界面UI分离的业务模块。在“Views”目录中包含了定义View的接口和Presenter类：
在“Services”目录中包含了与业务操作相关的Service类：
而“KBSample.SiteUser”项目则是专门的SharePoint项目(你可以选择使用VSeWSS，或是其它你习惯的工具)，其中包含了用来定义Web Part界面的View的实现。
在下面所示的Service接口中，定义了用来真正和SharePoint Object Model交互以获取数据的Service：
在Module被初始化时，将上面的Service注册到Container中：
对View接口的定义：
在Presenter里面，通过[ServiceDependency]来注入所依赖的Service对象(CWAB通过ObjectBuilder来干这件事)，同时定义了当View被载入时的操作：
View是通过一个用户控件来实现的，它实现了View接口，通过[CreateNew]来将一个新的Presenter对象注入进来：
别忘记在View被载入时，也要执行一下Presenter中的载入方法：
如果你熟悉Web Client Software Factory的话，那么在SharePoint开发中引入CWAB应该不是一件困难的事情。不过，由WCSF提供的那些Template和Recipe都不能使用了，项目的结构，需要我们来手工维护(这样反而给了我们很大的自由度:)。
在Wikipedia上，对“Web Application Framework”的定义是：
一个Web Application Framework是一个设计为支持动态Web网站、Web应用程序和Web Services开发的软件框架。Web Application Framework的目标是减少在Web开发中，与常见的开发工作有关的问题。例如，许多框架都提供了诸如数据库访问类库、模板框架和会话管理，同时，框架通常都能促进代码复用。（注：http://en.wikipedia.org/wiki/Web_application_framework）
Wikipedia的定义虽然清晰明了，但未免过于宽泛。根据这个定义，实际上，我们可以再将Web Application Framework分成两种：
■ Web Application Infrastructure Framework
■ Web Application Building Framework
Infrastrcture Framework提供了用来构建Web应用最底层的各种基础框架，诸如HTTP请求的截取和分配、网站与页面处理框架、会话管理、缓存等等。ASP.NET、PHP、JSP就属于Infrastrcture Framework。
Building Framework则是基于Infrastrcture Framework而构建起来的层次更高的Web应用框架，它的目的包括：
■ 将Web应用开发人员的视角从最底层的网站与页面框架，拉到更上面的基于具体应用的业务功能上
■ 用来支撑大型复杂的Web应用，例如超过上千个网站、上万个页面的Web系统，而且提供对服务器场、负载平衡的支持
在.NET领域，DotNetNuke就是一个典型的Building Framework。有了Building Framework，Web开发人员就可以不用从最底层开始构建Web应用系统，而是可以基于Building Framework，开始构建所需要的应用功能组件。一个Building Framework通常会包含下列内容：
■ 成熟的网站与页面结构框架，使得开发人员不用再基于页面、目录来管理整个Web应用
■ 完善且可扩展的用户、角色与权限管理
■ 灵活的UI模型
■ 内置的数据和文件存储能力
■ 具备完善的功能模块封装型
■ 对必要的功能接口提供API
■ 其他…
对于Web应用的开发来说，从静态网站到动态网站，从Infrastructure Framework到Building Framework，几乎是必然的。随着Web应用越来越复杂，开发人员面临的挑战也越来越大：如何维护和管理上千个网站、上万个页面？如何使Web应用能部署到网络负载平衡的环境中？如何使后台的Services与前台Web请求分离？如何提供完善的系统备份与迁移方案？如果我们必须基于Infrastructure Framework来解决这些问题，那么我们可能得将大部分的项目开发周期，花费在解决这些“底层架构”框架之上（虽然有些开发人员确实更喜欢开发“框架”，而不是一个可用的业务系统）。
当基于Building Framework之上进行开发时，开发人员可以更关注业务需求和业务功能的实现。通常，每一种Building Framework都会有一套专门的对功能模块进行封装和打包的模型，开发人员可以基于这一套模型，将自己开发的功能模块以标准化的方式进行封包。一方面，这样可以使得功能模块的部署变得更简单（避免了基于文件的手工拷贝方式），另一方面，开发人员也更容易的将自己开发的功能模块共享给社区（社区中使用同一套Building Framework的开发人员，可以方便的将拿到的功能模块以标准化的方式部署到自己的环境中）。
待续…
这个操作手册是之前帮一个客户写的，使用了SQL Server 2005 Mirroring来实现SPS 2003的门户的快速恢复，主要目的是在SPS 2003门户的突然不可访问（如数据服务器损坏、服务器群集所在网络不可用等）时，能够用最短时间在另外的地点恢复出门户网站。基本上MOSS 2007的原理类似，参考手册中的方法进行即可。
不过需要注意的是，在决定用SQL Server 2005 Mirroring来实现快速备份和恢复之前，你需要根据你的服务器场环境的具体情况，确定是否SQL Server 2005 Mirroring这种方式确实适用于你的服务器场环境。考虑的因素包括：
■ 对快速恢复所花费时间的要求
■ 网络情况
■ 评估Mirroring可能造成的性能上的损失
点击此处下载。
Chai同学已经在他的blog上贴了文章，讲述VS2010中，针对SharePoint开发的一些增强。虽说VS2010还有一点点远，但是先了解一下也是不错的。嗯，在VS2008上，应该至少还会发布一个VSeWSS 1.4出来。
新的项目模板类型：
内置在VS2010中的Server Explorer：
Feature属性设置界面（可以选择将Project中的指定Item添加到当前Feature中）：
新的Web Part开发模式，当我们新建一个Web Part时，会同时创建一个“绑定”的用户控件，在Web Part内会内置有包含此用户控件的代码，然后，我们可以直接基于这个用户控件进行可视化设计。
Package Explorer
对项目新增了“Package”操作，不再只能“Deploy”了。
QuickPart已经很久很久很久没更新了，这1个月将它做了一些小小的更新，其中最重要的一项更新是：QuickPart现在不但会搜索Web应用程序的“/wpresources”目录下放置的“.ascx”用户控件，还会搜索“/controltemplates”目录(及子目录)下放置的自定义“.ascx”。做这个看似没太多意义的更新，主要目的其实是可以让使用QuickPart的开发人员，直接使用Visual Studio 2005/2008（加上相应的VSeWSS），来管理、打包用户控件。也就是说，现在，大家可以不用辛辛苦苦的手工将做好的“.ascx”、“.dll”一个一个的拷贝到服务器的相应目录，而是可以使用SharePoint Solution Package的方式，快速的打包和部署可供QuickPart使用的用户控件了。
如何利用Visual Studio，来管理QuickPart部件，可以参考下面的video。如果觉得太小看不清楚，可以直接下载wmv格式的video。
(双击可放大到全屏，wmv格式下载)
链接：QuickPart 1.02下载
(注：标题中说的“SharePoint解决方案”，不是指SharePoint Solution Package(.wsp)中的那个“Solution”，也不是Visual Studio中用来包含各个子项目的“解决方案”，而是泛指各种基于SharePoint的应用。)
什么样的问题，是我现在被问得最多，也是最害怕被问的呢？嗯，就是“我对SharePoint开发没什么概念（/头绪/思路），你能给我讲讲吗？”其实，问这样的问题的人，不一定“真的”一点都不了解SharePoint的开发，他可能已经知道了Web Part要如何做出来、事件处理程序怎么写、SharePoint页面要如何进行定制化等等，但是，就是仍然觉得自己的大脑中没有一个清晰的、整体的SharePoint开发思路。一言以蔽之，提问者真正不了解的，准确来说，应该是SharePoint解决方案的完整的开发模型，到底是怎样的？或者换一个更cool的说法，就是所谓的开发方法论的问题。
在我的理解中，SharePoint解决方案的开发模型，确实绝对并非简单的Web Part如何开发、事件处理程序如何写之类的。当然，我不是说这些基础的、对SharePoint各个开发接口的了解不重要，实际上，如果连这些都还没有了解，那么也根本谈不上要了解更“上层”的SharePoint解决方案开发模型了。SharePoint解决方案开发模型应该包括但不限于下面这些主题：
■ SharePoint开发团队应该如何组织和分工？
■ 如何建立SharePoint开发、测试、集成（硬件和软件）环境？
■ 根据用户需求，如何进行SharePoint应用的整体设计（包括数据、界面、User Case…）？
■ SharePoint应用应该如何组织、分拆、组合？
■ 开发人员要如何有效的维护和管理SharePoint项目代码和内容？
■ 如何设计生产环境的拓扑和网络模型？
■ 如何按照信息架构，对SharePoint网站内容进行合理的分类和组织？
■ 如何创建一个高效的部署、迁移模型？
这也是为什么，很多人觉得，看完了《Office SharePoint Server 2007 开发入门指南》，仍然感觉对SharePoint开发存在着很多的疑问和未解。一本入门的书，很难将SharePoint解决方案开发模型的内容给装进去。而且，在编写这本书的2006年，SharePoint 2007甚至还没有正式发布，更不太可能有成熟的SharePoint解决方案开发模型可以借鉴。如果有人要撰写更新的SharePoint开发书籍，就有可能将更多的开发模型方面的内容放进去了:)。在MSN群里面和大家聊天的时候，也曾经头脑发热，提议再写一本相对高级的书，但是…不过，还是希望自己能陆续写一些相关的文章，放到blog上，和大家分享。
