kaneboy's SharePoint blog

使用过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. 1. 服务器硬件必须支持x64；
2. 2. SharePoint 2010服务器的操作系统必须使用Windows Server 2008 x64或Windows Server 2008 R2 x64；
3. 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. 1、 SharePoint Designer 2010功能更丰富，比如，它内置了更强大的工作流设计器，并且可以通过Business Connectivity Services直接连接到数据库；
2. 2、 在Visio 2010中，可以直接设计SharePoint 2010工作流，然后将设计好的流程导出至SharePoint Designer 2010的工作流设计器；
3. 3、 Groove 2007变成了SharePoint Workspace 2010，它现在可以将SharePoint网站中的文档库和列表数据，同步到客户端之中，以实现离线访问，同时允许用户在本地编辑文档库和列表数据，然后同步到SharePoint网站中。

为了迎接SharePoint 2010，决定订购一台新笔记本，用来进行SharePoint 2010开发、测试和演示。我对新装备的要求是：

1、轻便。由于我经常有机会进行演示和讲演（比如下个月即将开始的TechED China 2009），所以我希望这台新装备足够轻便，当我带着它外出时，不会让我感到太大的“压力”。
2、足够的性能。由于我的开发环境基本上都是建立在虚拟机里面，所以我希望它可以轻松的运行SharePoint 2010虚拟机。

最后我订购的是ThinkPad X200，它配置了酷睿2 P8600，6GB内存（单条4GB的笔记本内存太贵了，以后再升级到8GB吧），320G硬盘，而且，它还足够轻便。从昨天晚上拿到了它之后，就开始给它安装Windows Server 2008 R2，并使用它启动了一个SharePoint 2010的Hyper-V虚拟机。在为虚拟机分配了4.5GB内存之后，它运行得相当的流畅。:)

 

新装备到手之际，同时也听到了某些同志准备订购ThinkPad T400，8GB RAM，2GB Intel Turbo Memory的传闻...

从北京时间昨天晚上开始，随着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月份发布。

一年一度的TechED将在今年11月5日-7日，在北京国家会议中心登场。今年的TechED取消了上海和广州站（金融危机的原因？），而只保留了北京站。对于不少华东华南的朋友来说，这真是一件纠结的事啊...在本次TechED China 2009中，当然少不了有关于SharePoint的课程，而其中大部分，都是有关于SharePoint 2010的。这应该也将是国内第一次SharePoint 2010技术课程的集体出场。

SharePoint 2010 新技术揭秘
SharePoint 2010 系统管理员秘籍
SharePoint 项目实施团队的成功之道
SharePoint内容管理及合规一致性
从隔靴搔痒到探囊取物 - SharePoint 2010数据访问新特性
用Visual Studio 2010构建SharePoint 2010应用实战体验
先睹为快 -- Office 2010全新生产力平台大揭秘
将分散的信息汇聚为知识和价值 - SharePoint 2010企业搜索
强强联手：Office 2010 与 SharePoint 2010协同办公
SharePoint 2010 Business Connectivity Services：外部业务数据整合利器
InfoPath 2010亮剑 -- 为SharePoint列表设计表单应用
SharePoint 2010 与 Access 2010 构建团队级数据应用

上面的课程中，粗体标注的是我主讲的课程。欢迎捧场！:)

更多有关TechED China 2009的信息，请参考TechED网站。完整课程表请点击这里。

大约一年前，我曾经在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（由于在版权方面的考虑，其中删除了部分内容）。

经过“漫长”的等待之后，《Microsoft Office SharePoint Server 2007 管理员指南》终于可以在china-pub上预订了。

自从Microsoft Office SharePoint Server 2007发布以来，虽然已经有数本有关开发类的中文书籍面世，但还没有一本权威、全面的，专门讲述SharePoint管理的书籍在国内出现。本书的英文版原著《Microsoft Office SharePoint Server 2007 Administrator’s Companion》，是一本由Bill English和众多SharePoint MVP、SharePoint专家共同撰写的，由微软出版社出版的权威性Microsoft Office SharePoint Server 2007管理类书籍。我相信，将本书的中文版本介绍给国内的SharePoint社区，具有重要的意义。

Microsoft Office SharePoint Server 2007是一个复杂的平台级产品，在很多时候，SharePoint的扩展开发与管理配置很难明显的分开。也就是说，如果您是一位SharePoint开发人员，您肯定会发现在项目开发过程中，需要对SharePoint管理和配置有所了解。同样，如果您是一位SharePoint系统管理员，在进行日常系统维护或系统升级操作过程中，有时候也同样需要具备一定的开发知识。所以本书的读者群并非仅仅包含SharePoint系统管理员和网站管理员，同样也包含了SharePoint开发人员和架构师。如果不能对SharePoint的管理和配置有全面且深入的了解，开发人员和架构师很可能在项目开发过程中举步维艰。

下面是一些关于此书内容和面向群体的Q&A，如果您不知道是否应该购买此书，可以参考此Q&A。

Q：我是一名SharePoint系统/网站管理员，这本书是不是就是为我准备的？
A：没错。如果您的工作就是对整个SharePoint系统，或者某个SharePoint网站进行管理，那么绝对有必要购买这样一本全面、细致的书籍，作为您日常工作的参考。

Q：我是一名SharePonit开发人员，平时的工作主要是基于SharePoint进行Web应用的开发，我有必要看这本书吗？
A：绝对有必要。如果您不能清楚的了解SharePoint管理和配置的一些细节，很多时候甚至难以确定如何对SharePoint进行扩展开发。何况很多时候，SharePoint系统的配置与开发之间的界限，是非常模糊的。比如，编写一个Feature定义XML文件，到底算是配置工作？还是开发工作？我一直认为，一个好的SharePoint开发人员，绝对应该至少是一个合格的SharePoint管理员。

Q：我是整个实施团队的PM/Architect/Tech Lead，这本书对我有帮助吗？
A：在本书中，除了具体的管理和配置指导之外，还包含了大量的规划（Planning）方面的内容。在您对整个系统进行设计时，这些规划指南将帮助您确定整个系统的物理拓扑、逻辑结构、分类体系、容量设计、安全设计等等等等。没有这些良好的规划，要想成功的实施一个SharePoint系统，几乎是不可能的。所以此书中所包含的大量规划指南、最佳实践等内容，将有效的指导项目团队的架构师，完成和完善整个SharePoint系统的设计。

Q：这本书和其他SharePoint管理类书籍的区别是什么？
A：完整性。本书的英文原版是由众多SharePoint MVP所撰写，由MS Press出版所发行的一本“权威之作”。它的内容相当的完整，几乎覆盖了规划、安装、升级、日常管理、监控、备份、灾难恢复等方方面面，而且每个方面的内容都具备相当好的可操作性。

Q：我听说下个版本的SharePoint 2010就要出来了，我现在还买SharePoint 2007的管理书籍，有必要吗？
A：首先，SharePoint 2010预计的发布时间是在2010年上半年，就算它能在2010年5月份发布，离现在也还有9个月时间。其次，以SharePoint产品现在的定位和市场情况而言，大量企业已经（或正在）基于SharePoint 2007构建各种Web应用。这些已经构建好的，或是正在构建的应用系统，想必不会在SharePoint 2010发布时就立即升级。甚至SharePoint 2010正式发布之后，也不见得所有SharePoint新项目就全部会基于新版本构建。所以在现在这个时间点，就考虑这本书是否已经过时的问题，似乎尚早。

Q：本书的中文版翻译质量如何？
A：翻译质量总是一个具有争议性的话题。作为本书的主要译者，如果我说这本书的翻译质量很好，似乎有自卖自夸的嫌疑。但我可以肯定的告诉大家的是：(1)它的所有译者都是了解并精通SharePoint的技术人员；(2)除了很少量没有必要且不影响理解的插图之外，本书绝大部分的插图都已经更换为了中文版；(3)本书中几乎所有术语都对照SharePoint Server 2007中文版，进行了认真细致的参照翻译。

Q：如果有什么理由不让我买这本书，那会是什么？
A：售价太贵。我也没想到出版社会将定价定为￥128.00元（折后约为￥96.00元），我之前一直猜想定价只会在50左右。但由于定价权在出版社，所以我也只能接受并尊重。从译者的立场，我当然认为读者从此书中获得的价值远超定价，但作为购书人的您，肯定不一定做此想。:)

最后，我将此书前言部分的内容介绍复制在了后面，您可以点击这里查看。

最近自己的工作有了些许变化。从8月19号开始，我正式从微软公司辞职，并加入了HP公司GPASE（Global Practices & Application Services Engineering）部门。加入HP之后，我的工作仍然会围绕着SharePoint产品和技术（所以，我仍然是在SharePoint领域之中）。同时，我也将继续为社区贡献我的力量。

谢谢大家继续关注我的blog！

前两天，从infoq上看到了这篇"你吓着我了，MOSS"。嗯，实际上，我想说的是：这本来就是一个很容易被吓到的时代。

如果我在这里说，SharePoint是多么多么的易用，对开发人员多么多么的友好，那么一定会有不少曾经被SharePoint"摧残"过或是正在被它"摧残"的开发人员，想要跳进面前的电脑，然后沿着长长的网线冲到我面前，掐着我的脖子前后摇晃着喊道："你瞎掰你瞎掰你瞎掰..."所以，我只好承认，如果你开始学习SharePoint，最开始的一段时间很可能会是非常艰难的，甚至你需要花费相当长的时间，才能对SharePoint的全貌有一个清晰的了解。从这个角度来说，SharePoint确实很能吓到我们。

但是，在这个"最好的"也是"最坏的"时代，对于一个开发人员来说，还有什么是容易就能做到的呢？只需要学会Delphi就能搞定一切的时代，已经一去不复返了。如今要在开发人员这个行业生存下来，每个人都必须不断的阅读大量的内容，学习各种花样翻新的技术。想想看，即使只是做一个不算复杂的Web网站，你也需要了解CLR、C#、ASP.NET、HTML、CSS、JavaScript、ADO.NET、ORM、Linq、Flash/Silverlight、IIS...你每天都会从网络上看到各种新产品、新技术、新名词，而看起来似乎每一样你都应该去学习。不管你是在哪个平台上（.NET/Java/Mobile...）做开发，这种情况几乎难以避免。你总会发现，每次你觉得对一个东东有了比较深入的了解，它的下个版本似乎就快发布了。客户的要求越来越高，老板却希望你一个人搞定所有的问题，而你开发的系统却越变越复杂，你希望通过引入一个ABC类库或XYZ框架来简化遇到的问题，却很快发现它们会带来更多的复杂性，而你还需要把各种东东整合在一起。

我其实要说的是，好吧，即使你打定主意，不去碰SharePoint，那么不管你打算去碰什么，情况也不会好到哪里去。这就是我们所处的这个时代的现状，我们需要构建前所未有的庞大系统，我们会遇到前所未有的艰巨挑战，我们所使用的是前所未有的复杂工具，而我们需要自己成为前所未有的"强大"的程序员。如果我们不能让自己的神经变得前所未有的坚强，那我们就只能每天被吓到。:)

今天，微软“半公开”发布了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开发 - 模式与重构（涂曙光）

5月30日，我会参加SharePoint技术峰会，并贡献一个讲座：《SharePoint开发：模式与重构》（或者可以叫做《如何将模式应用到你的SharePoint程序，并重构它》）。这个讲座面向的对象是SharePoint Developer和Architect。

这次活动的详细信息，请参考www.msiw.net。活动地点在霄云路现代汽车大厦18楼，参与者不需要负担任何门票费用，但午餐似乎需要自己解决。:)

更新：我在峰会上使用的PPT，以及现场显示的Demo源码下载。

Windows SharePoint Services 3.0 SP2 下载
SharePoint Server 2007 SP2 下载

最近在忙着给出版社交《Microsoft Office SharePoint Server 2007 管理员指南》的翻译稿，所以实在没有时间写blog了。希望等过了这阵子之后，再写一些新的东西。

WSS 3.0和MOSS 2007都发布最新版本v1.5 SDK了。

WSS 3.0 SDK v1.5下载
MOSS 2007 SDK v1.5下载

在SharePoint从上个版本升级到当前版本时，从产品名称中去掉了"Portal" (SharePoint Portal Server 2003 –> Microsoft Office SharePoint Server 2007)，而下个版本将从产品名称中去掉"Office"，其产品名称将是"Microsoft SharePoint Server 2010"。

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展示了完整的配置过程，以及如何做一个定制的登录界面。

第一部分：
 Video: AD Auentication with Forms-Style Login in SharePoint

第二部分：
 Video: AD Authentication with Forms-Style Login in SharePoint (Part 2)

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)

SharePoint Team Blog中公布了VSeWSS 1.3 CTP的消息，请从这里下载。1.3最大的改进之一，是提供了x64版本，以支持在x64机器上进行开发。另外，我最喜欢的改进包括：

新增更多的Project Item，比如，通过"Root File"直接往12hive里面放文件。
 
VSeWSS的智能化程度也高了一些，如果在Project Explorer里面更改了文件夹名，或是直接删除了文件夹，会自动对SharePoint Solution进行更新，不会像以前那样，直接在WSP View告诉你一个错误信息。

这个新增Feature的对话框很可人...


终于有了独立的"Package"选项，而没有必要仅仅为了生成一个WSP包，却不得不使用"Deploy"选项，先生成WSP，再被强迫进行部署...另外，"Quick Deploy"里面的功能很实用。
 

总结：通过正确的"模仿"WSPBuilder很早就有了的好用且实用的功能，相比1.2版本，这个新版本的可用性明显提高了不少。