打开Default.Mater可以发现，三个导航栏的实现各有不同，顶部的导航栏是通过一个SharePoint:DelegateControl动态加载asp:SiteMapDataSource作为数据源的，而左侧的两个则是通过SharePoint:DelegateControl动态加载一个SPNavigationProvider实现的数据源。

         顶部的导航栏代码如下:

<SharePoint:AspMenu
   ID="TopNavigationMenu"
   Runat="server"
   DataSourceID="topSiteMap"
   EnableViewState="false"
   AccessKey="<%$Resources:wss,navigation_accesskey%>"
   Orientation="Horizontal"
   StaticDisplayLevels="2"
   MaximumDynamicDisplayLevels="1"
   DynamicHorizontalOffset="0"
   StaticPopoutImageUrl="/_layouts/images/menudark.gif"
   StaticPopoutImageTextFormatString=""
   DynamicHoverStyle-BackColor="#CBE3F0"
   SkipLinkText=""
   StaticSubMenuIndent="0"
   CssClass="ms-topNavContainer">
  <StaticMenuStyle/>
  <StaticMenuItemStyle CssClass="ms-topnav" ItemSpacing="0px"/>
  <StaticSelectedStyle CssClass="ms-topnavselected" />
  <StaticHoverStyle CssClass="ms-topNavHover" />
  <DynamicMenuStyle  BackColor="#F2F3F4" BorderColor="#A7B4CE" BorderWidth="1px"/>
  <DynamicMenuItemStyle CssClass="ms-topNavFlyOuts"/>
  <DynamicHoverStyle CssClass="ms-topNavFlyOutsHover"/>
  <DynamicSelectedStyle CssClass="ms-topNavFlyOutsSelected"/>
 </SharePoint:AspMenu>
 <SharePoint:DelegateControl runat="server" ControlId="TopNavigationDataSource">
  <Template_Controls>
   <asp:SiteMapDataSource
     ShowStartingNode="False"
     SiteMapProvider="SPNavigationProvider"
     id="topSiteMap"
     runat="server"
     StartingNodeUrl="sid:1002"/>
  </Template_Controls>
 </SharePoint:DelegateControl>

    其中aspmenu的使用没什么难度，用户可以自定义CSS样式和定义一些显示的级次。这里插入一个SharePoint CssRegistration控件的用法，就是自定义CSS文件，前面有一篇文章我曾经专门讲过如何自定义CSS文件，这里介绍一个CssRegistration的用法，在SharePoint页面的Head中加入:

<SharePoint:CssRegistration name="<% $SPUrl:~Site/CustormStyle.css%>" runat="server"/>

其中,name为该CSS文件的地址。

    值得一提的是下面的DelegateControl控件动态加载了一个SiteMapDataSource，其中SiteMapProvider="SPNavigationProvider"才是真正的指定数据源，而后面的StartingNodeUrl="sid:1002"则定义了该站点导航栏的起始位置，注意左侧的导航栏的起始位置和顶部的就不一样。因为顶部的导航栏通常都是从SiteCollection开始的，而左侧的导航栏是从当前站点开始的。ok,就是说可以通过更改顶部导航栏的MaximumDynamicDisplayLevels来让顶部导航栏显示更多的级次，从而显示站点中定义的List , Document Libraries等。

   开发人员可以通过定义一个XMLDataSource，然后将ASPMenu的DataSourceID指向XMLDataSource的ID来实现自定义的导航栏。例如写一个XMLDataSource 如下。

<asp:Menu DataSourceID="DemoXmlDataSource" ID="DemoCustomMenu" runat="server" 

BackColor="#F1F1F1" DynamicHorizontalOffset="2" Font-Names="Verdana" ForeColor="#990000" 

StaticSubMenuIndent="0" Orientation="Vertical" StaticDisplayLevels="2" ItemWrap="true" 

MaximumDynamicDisplayLevels="0"> 

<DataBindings> 

<asp:MenuItemBinding DataMember="siteMapNode" NavigateUrlField="url" 

TextField="title" ToolTipField="description" ValueField="title" /> 

</DataBindings> 

</asp:Menu> 

<asp:XmlDataSource DataFile="sitemap.xml" ID="DemoXmlDataSource" runat="server" XPath="/*/*"></asp:XmlDataSource> 

其中sitemap.xml文件如下。

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

<siteMap xmlns="http://demo/testsite/SiteMap" > 

<siteMapNode title="CustomMenu" url="CustomMenu.aspx" description="Go To Custom Menu"> 

    <siteMapNode title="Menu Link 1" url="MenuLink1.aspx" description="Go To Menu Link 1" /> 

    <siteMapNode title="Menu Link 2" url="MenuLink2.aspx" description="Go To Menu Link 2" /> 

</siteMapNode> 

</siteMap> 

     同样开发人员可以在代码中控制导航栏控件，下面的代码DEMO了使用C#修改并添加了一个导航栏控件(其中SiteDemo为一个SPWeb对象)。

SPNavigationNodeCollection nodesDemo = siteDemo.Navigation.QuickLaunch; 

SPNavigationNode navDemoNode = new SPNavigationNode("Custom Menu", "#", false); 

nodesDemo.AddAsFirst(navDemoNode); 

SPNavigationNode subnavDemoNode1 = new SPNavigationNode("Menu Item 1", "http://demo:8001/", true); 

nodesDemo[0].Children.AddAsFirst(subnavDemoNode1); 

SPNavigationNode subnavDemoNode2 = new SPNavigationNode("Menu Item 2", "http://demo:8002", true); 

nodesDemo[0].Children.AddAsFirst(subnavDemoNode2); 

siteDemo.Update(); 

   1 使用Asp.net 2.0的Webpart，声明SafeContorl之后上载到Sharepoint的Webpart gallery中，MSDN上的Walkthrough: Creating a Basic Web Part 有详细介绍.

   2 使用SharePoint的Webpart,装一个VS Extensions for SharePoint之后有一个项目类型叫做webpart，写一个webpart，然后F5,就会把webpart部署到你的SharePoint的站点中.实际上也是部署了一个Feature. 其原理MSDN上也有介绍:Walkthrough: Creating a Basic SharePoint Web Part 

   3 kaneboy在他的blog中提到过使用Feature的部署DelegateContorl的方式部署一个ascx文件到站点集的Feature。

   以上三种方式各有优缺点，前两种方式采用纯粹的Webpart的形式，开发起来很麻烦，特别是一些丰富的用户界面会变得很麻烦。第三种方式虽然解决了前两种方式的不足，但是没有Code-behind，做企业级开发把code写在ascx文件中实在有点不合适，而且使用Feature部署以后管理起来不是很方便。那么今天我就来Demo一种使用Code-behind用户控件作为WebPart的方式，而且将部署的UserContorl便于管理。

   这里使用一个工具叫SmartPart,这个工具在WSS 2.0时代就有，现在又针对与WSS 3.0的版本。下载回来一个msi安装包，不知道为什么我在两个VPC上安装都没有成功，解压缩到临时目录下之后就没反映了。没办法，一些还得自己动手丰衣足食阿。在临时目录下有一个Cab文件，把这个文件打开之后研究一下，大概明白了安装的步骤。

  Step(1): 将SmartPart.dll部署到GAC.

  Step(2):新建一个Web Project，在里面开发你的用户控件，Demo的用户控件叫UCPart.ascx。
  前台代码:

<%@ Control Language="C#" CodeFile="UCPart.ascx.cs" Inherits="DemoWebPart.UCPart" CompilationMode="Always" %>
<asp:TextBox ID="txbDate" runat="server"></asp:TextBox>

  后台代码:

using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;

namespace DemoWebPart
{
    public partial class UCPart : System.Web.UI.UserControl
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            this.txbDate.Text = DateTime.Now.ToShortDateString();
        }
    }
}

  功能很简单，就是在后台代码中为一个textbox赋一个值。编译一下通过之后，把这个用户控件连同其后台代码文件copy到<%IIS Root Dir%>\wss\VirtualDirectories\xxxx\UserContorls下。

  其中<%IIS Root Dir%>为IIS的根目录，xxxx为当前Web Application的端口号。如果你第一次做这个操作，是需要手工建立一个UserContorls文件夹的。

  同时更改<%IIS Root Dir%>\wss\VirtualDirectories\xxxx\Web.Config.声明SaftContorl.

<SafeControl Assembly="SmartPart, Version=1.1.0.0, Culture=neutral, PublicKeyToken=dd064a5b12b5277a" Namespace="SmartPart" TypeName="*" />

  Step(3): 把SmartPart的临时目录下的两个dwp上载到站点的Web Part Gallery中。

  Step(4): 随便找个页面在设计模式下添加WebPart，会发现刚刚添加的两个WebPart.

   选择添加SmartPart List之后，在WebPart的属性中就可以选择到你刚刚放到UserContorls下面的UserContorl。

  添加到页面上看一下，哦.....测试通过...

  关于另外一个SmartPart的用法类似，只不过不是列表选择的形式，可以任意UserContorl的定义路径。

  使用这种部署Webpart的方式的好处有两个:

  1、支持Code-behind.

  2、便于管理已经部署的UserContorl.

  Step(1):在网站中创建一个页面,存放于一个文档库中,这里我创建的页面在文档库SiteCollectionDocuments下testpage.aspx,那么这个页面的引用路径就是<%siteurl%>/SiteCollectionDocuments/testpage.aspx .

  Step(2):在12\TEMPLATE\FEATURES文件架下新建一个文件夹叫LinkToPage,在文件夹下创建Feature.xml.内容如下.

<?xml version="1.0" encoding="utf-8" ?>
<Feature Id="C86A92EA-A5D3-4d65-855C-0557AE5D065A" 
    Title="Link To Page"
    Description="This example show how to create a menu linke to a customize page!"
    Version="1.0.0.0"
    Scope="Site" 
    AlwaysForceInstall="TRUE" 
    xmlns="http://schemas.microsoft.com/sharepoint/">
  <ElementManifests>
    <ElementManifest Location="LinkToPage.xml" />
  </ElementManifests>
</Feature>

  Feature元素的几个属性说明一下:

  Id:这里要使用vs的guid工具生成一个guid,copy过来就可以

  Title 和 Description分别是Feature的标题和描述.

  Scope这个属性比较重要:是一个枚举值,是用来描述这个feature的作用范围.这里选择:site

  AlwaysForceInstall:这个属性设置为true 可以在重复安装这个feature中自动覆盖原来安装的那个相同的feature.

  ElementManifest的location属性制定一个描述feature内容的xml文件,这里叫做LinkToPage.xml

  Step(3):建立上一步中的LinkToPage.xml,内容如下.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <CustomAction Id="LinkToPageInactionsMenu"
    RegistrationType="List"
    RegistrationId="101"
    GroupId="ActionsMenu"
    Location="Microsoft.SharePoint.StandardMenu"
    Sequence="1000"
    Title="Link To Page"
    Description="This is action menu"
    >
    <UrlAction Url="~sitecollection/SiteCollectionDocuments/testpage.aspx"/>
  </CustomAction>
    <CustomAction Id="LinkToPage"
      RegistrationType="List"
      RegistrationId="101"
      GroupId="NewMenu"
      Location="Microsoft.SharePoint.StandardMenu"
      Sequence="1000"
      Title="Link To Page"
      Description="This is new menu!"
     >
  <UrlAction Url="~sitecollection/SiteCollectionDocuments/testpage.aspx"/>
    </CustomAction>
</Elements>

  这个xml文件中可以多个CustomAction来描述feature的实际内容,这里采用了两个。

  Location和groupid两个属性分别指定该feature是定义了哪两个菜单.

  Sequence属性指定新增加的菜单项在这个菜单中的排序，设置的大一点该菜单项排列就靠后.

  Title 和 Description分别是该菜单项的标题和描述.

  UrlAction属性指定了该菜单项的连接到的页面,当然了,这个demo连接到的是我们在第一步中建立那个页面.这里有一个相对路径的问题,~site 表示站点的主目录, ~sitecollection  表示站点集的主目录.因为我的demo是做在一个站点集下面的,所以采用~sitecollection后面是连接文件的相对路径..

  Step(4):下面就是将这个feature部署到站点,因为可能会经常使用到部署feature这样的功能,那么我们写一个通用的bat文件来实现feature的部署,内容如下.

@rem======================================================================
@rem
@rem    setupfeature.bat
@rem
@rem======================================================================

@echo off
setlocal
pushd .

goto InstallFeature


@rem----------------------------------------------------------------------
@rem   InstallFeature
@rem----------------------------------------------------------------------
:InstallFeature
    set SPAdminTool=%CommonProgramFiles%\Microsoft Shared\web server extensions\12\BIN\stsadm.exe
    set TargetUrl=http://mymoss:8001
    set FeaturePath=LinkToPage\Feature.xml
   
    echo InstallFeature %FeaturePath% 
    "%SPAdminTool%" -o installfeature -filename %FeaturePath%

    echo Activating feature %FeaturePath% 
    "%SPAdminTool%" -o activatefeature -filename %FeaturePath% -url %TargetUrl%

    echo iisreset
    iisreset

  其中每次只要更改TargetUrl和FeaturePath就可以了,是不是方便了很多.

  实际上看这个文件中的内容就知道,通过stsadm命令的-o instanllfeature安装这个feature,然后通过stsadm命令的-o activatefeature激活这个feature,然后iisreset一下.将这个bat文件放在12\TEMPLATE\FEATURES,双击执行就可以.


  Step(5):进入站点新建一个文档库，看看文档库的菜单中是不是多出了两项?

  到网站设置的网站集功能中看看,是不是有一个Link to Page的feature已经被激活.

  Step(6): 通过列表的菜单我们可以链接到刚刚所建立的新页面，但是怎么能通过这个链接传递数据呢?也就是说可以在testpage.aspx中获取列表的Id.  ok,将UrlAction更改为<UrlAction Url="~sitecollection/SiteCollectionDocuments/testpage.aspx?listid={ListId}"/> ,  保存文件之后重新运行installfeature.bat，新建一个列表，重新使用该功能定位到testpage.aspx，看看是不是能在querystring中获得列表的guid了.

  ok,以上就是使用feature来Feature定义站点中的菜单项的DEMO.
  Enjoy it....

   模板实际上是包括站点模板和列表模板，当用户通过Web界面或是SharePoint Designer更改一个站点或是列表的定义时，模板中仅仅记录了更改的内容而并没有包含全部定义。一个标准的自定义模板中实际上是引用了其原始的站点定义，所以当一个站点模板部署到一个新的站点上时，其引用的站点定义发生了变化，站点模板有可能就会出错。

   站点模板文件的后缀名为.stp，站点模板stp文件中包含了一个站点模板库和一个Mainfest.xml文件，stp文件实际上是一个cab文件，使用站点设置中的将网站另存为模板的功能，可以将把网站模板导出到网站模板库中，下载该stp文件，可以把.stp的后缀名改称.cab打开看看里面的内容。

   注意在使用将网占另存为模板这个功能的时候，可以选择包含当前站点的数据的。而保存的.stp文件也可以通过stsadm导入到一个新的站点中。例如导出的stp文件为 DemoSite.stp ，则执行

stsadm -o addtemplate -filename DemoSite.stp -title NewDemoSite -description It's a new site from DemoSite Template

 结果就是可以建立一个新的站点名字为NewDemoSite。

  站点定义是用来记录站点类型的，这里的站点类型指的是类似于空白站点、工作组站点、会议类型站点等等的站点，在MOSS 2007中有一句话叫做:Everything is site. 没错，所有的MOSS的用户界面都是依托于站点实现的，其中包括MOSS的管理中心和SSP宿主站点中的定义，这些站点实际上都是依托站点定义实现的，每一个不同类型的站点都有其对应的一套站点定义。像MOSS中新增加的blog站点,wiki站点实际上只是新增一个站点的类型而已，在WSS底层方面并没有为这些不同站点定义什么特殊的功能点。在12-hive文件夹下面有一个template目录，里面是WSS中各种站点类型的定义文件。如果你更改了这些站点定义文件，那么之后新建的站点也会随之更改。打开站点定义的内容会发现，站点定义的内容比较复杂，有xml\aspx\ascx\master\dot\html各种各样类型的文件，其中xml文件中存储了站点的定义规则而其他类型的文件都是为了实现这个站点定义所使用的功能性文件和模板文件。

  实际上开发者也可以自己对站点定义新增aspx页面文件，但是这些新增的文件都应处于一个unghosted的状态，并且要在web.config中声明为安全类型，否则将不能被执行，这是为了弥补上载aspx文件后未经声明而采取服务器端调用产生的漏洞。

  站点定义中包括著名的四个xml配置文件，可以说这四个文件包含了一个站点的主要定义。
  Onet.xml:最重要的定义文件，其中包括站点导航区域、列表定义、模板定义、内容类型定义、站点的配置和功能模块信息等等。位置在:\TEMPLATE\1033\STS\XML.

  Schema.xml:定义了列表的视图、表单、特殊字段，每一个不同的列表类型有其独立的Schema.xml。位置在:\TEMPLATE\1033\STS\LISTS\.

  WebTemp.xml:包含了站点定义的一些配置信息。位置在:\TEMPLATE\1033\XML.

  DocIcon.xml:顾名思义,定义了不同文档类型的打开方式和图标。位置在:\TEMPLATE\XML.

  微软强烈不推荐更改以上四个文件，即使新的站点定义也要在试图修改这四个文件。因为这四个文件的更改可能会导致你的MOSS站点彻底崩溃或影响以后的升级等等...

  那么当开发人员对一个站点进行定制化开发的时候，使用哪种方法比较合适呢?其实两种方式有各自的优缺点，要根据不同情况来选择，微软在MSDN中给出了如下的一些比较：

•   站点定义比站点模板的优势在于:

  数据直接存储与web server上，性能上要好。

  直接修改Schema.xml能达到更高的定制化程度。其中包括新的文件类型定义、视图样式、一些菜单的更改等等。

•   站点定义的缺点有:

  自定义站点的难度比较高，需要开发人员熟悉站点定义所使用的CAML语言。

  开发站点定义文件之后，部署一个新的站点定义是一个难题。

  站点定义中不能指定站点的主题。

  站点定义需要具有服务器的管理员权限，直接操作服务器的文件。

•   站点模板比站点定义的优势在于:

  站点模板的建立比较简单，通过Web界面定义过的站点可以直接导出成为一个.stp文件，几乎没有任何难度。实际上大部分站点模板中能自定义的东西在通过Web同样可以对站点进行定义，然后导出成.stp文件。站点模板易于部署，一行命令就可以搞定。

•   站点模板的缺点在于:

  站点模板不是用来在开发环境中开发的，使用站点模板对站点进行定义，如果站点比较多的话会比较麻烦。站点模板依赖于站点定义，一旦生成站点模板的那个站点定义类型改变了，站点模板就不能在使用了。

    step(1) : 在本地建立一个CSS文件，命名为mycss.css.

    step(2) : 在需要定义CSS的站点上建立一个文档库，然后将建立好的mycss.css上载到这个文档库当中。

    step(3) : 在站点设置中，选择外观选项下的母板页。在站点设置中有两个母板页选项，一个是在外观选项中，一个是在库选项卡中，我们这里要选择的是外观选项下的。

    站点设置的外观选项中有可能没有母版的选项，是由于禁用了站点的feature“Office SharePoint Server 发布基础架构”，到站点集功能中启用这个feature即可。

    step(4) : 在母板页设置页面中，设置备用CSS URL为指定的文件，浏览选择上载到文档库中的mycss.css，注意这个选择窗口挺有意思，做得和windows的风格很接近，需要双击才能打开其中的文件夹。

    step(5) : 在母板页中定义css文件如:

.ms-titleimagearea
{
cursor : hand;
}

    重新上载这个mycss.css，要选中覆盖原有版本。

    step(6) : 看看站点的图标，是不是上去鼠标的指针会变成hand。

    在MOSS定义css文件需要对页面内部的元素及其CSS比较熟悉，这里推荐一个工具，The Internet Explorer Developer Toolbar， 是微软推出的一个针对与开发人员的IE插件，安装这个插件之后在IE的View->Explorer Bar中会添加一个DOM Explorer，利用这个工具的"Select Element by Click"功能，会很方便的在当前页面中找到元素的CSS定义，当然了这个工具的功能远远不限于此。

    有两个需要提示的地方：

    tip (1):页面中通用的一些菜单的样式往往是经过多次CSS定义的，因此要对这些样式进行重定义需要对多个CSS进行重新定义。

    tip (2):尽量从站点定义的theme.css中把整个样式表copy过来之后对其进行重新定义到你的自定义css中。

    enjoy it....

   熟悉微软Office产品线的人都知道，MOSS 2007的上一个版本SPS 2003的全称是 Office Sharepoint Portal Server，在新版本中，微软去掉了Portal一个词。从这个角度很清楚地看到微软对MOSS 2007的定位，是的，MOSS 已经不再仅仅是一个Portal Server了，虽然Portal仍然是其最主要的一块功能，同时MOSS是一个集成了内容管理(Content Management)、商务智能(BI)、工作流(Workflow)、企业搜索引擎(Enterprise Search Engine)、应用整合(EAI)在内的平台级服务器。

   下面对MOSS 2007的新功能作一个简要概述。

•    Portal

   上面提到过Portal仍然是MOSS 2007最主要的一项功能，照比SPS 2003功能有大幅度提升的同时，去掉了2k3中的让人容易混淆的一些概念，使得Portal在架构上更加清晰和明确。门户的概念本身就是为企业提供一个内容管理、知识管理、工作协作的平台。在MOSS 2007中，可以使用全新的站点模板(Site Templet)和站点定义(Site Definitions)的功能定制个性化的门户，使得最终用户可以通过更改预先定义的站点模板和站点定义来更改网站的外观，当然这点在2k3中也可以实现，只不过2k7提供了更加便于操作的一些新功能。MOSS 2007同样支持个人站点这个概念，可以通过两种方式实现个人站点，一种是用户自定义创建的形式，另外一种形式是通过管理员导入User Profile生成个人站点。同样支持最终用户设定一些个人的Web Part，例如我的同事、我的工作之类。User Profile是在MOSS 2007中的一个新功能，MOSS 2007提供了基于不同的形式用户机制，默认是基于AD或workgroup(单机版)的，可以通过更改UserProfileProvider连接到其它的基于LDAP的用户数据库，同样也可以基于ASP.NET 2.0的MemberShip用户库，这点就为将MOSS 2007推广到Internet提供了一个很好的基础。User Profile实际上是将外部用户数据读入到MOSS中，形成针对用户的Profile，基于UserProfile可以授权用户对List或Webpart的可见性(注意对于List列表的内容和Web part的用户功能并不能通过User Profile的授权来控制)。同样MOSS对于读入的User Profile进行存储之后可以进行定制化的扩展。让人感到兴奋的是MOSS终于提供了对移动设备的支持，所有的可以通过浏览器浏览的Web页面都有其移动设备版本。

   实际上MOSS中对SPS中的一些站点的概念作过调整，去掉了原来区域和门户这两个概念。在MOSS中，最顶级的一个概念是Web Application，基于Web Application可以建立Site Collocation，SiteCollocation下面是Site，当然了，每一个Site Collocation下面的第一个Site当然就是RootSite，其他的都是基于Root Site 的Child Site。Site实际上是MOSS中最重要的一个对象，在MOSS的概念体系中又一个句话:Everything is Site。实际上连MOSS 的管理站点和SSP管理站点(Shared Service Provider,这个概念很重要，后面会详细说明)都是一个Site。

•    Enterprise Content Management(企业内容管理)

   MOSS 2007实际上是整合了Sharepoint Portal 2003和微软的另一个早期的服务器产品Content Management Server 2002两个服务器产品，所以Enterprise Content Management是MOSS 2007中最重要的一个服务之一。MOSS 2007的Enterprise Content Management主要包括三部分：文档管理(Document Management)，记录集管理(Records Management)和Web内容管理(Web Content Management)。

   文档管理(Document Management)主要有几点值得兴奋的，InforPath Work Forms、Document Information Pannel和Document Converters.InforPath Work Forms实际上是通过Form Server实现的一个很实用的功能，基于Form Server可以大幅度提高原来InforPath的功能，实现完全基于Web的InforPath。Document Information Pannel这个功能显得更加实用，因为Office 2007的文件格式是完全开发的XML格式，实际上就在技术上允许了对Office Document进行扩展，使用Document Information Pannel可以对固定模板的文档进行格式化的信息收集和提取。Document Converters是提供了一个文档转换的功能。

   记录集管理(Records Management)对于企业来说是一个极其实用的功能，多数企业在信息化建设中都希望实现企业内的数据、文档等内容进行版本控制、知识库建设等功能，MOSS 2007提供了对企业内文档和数据的版本管理、生命周期控制、内容类型控制、文档审核、与企业内部的RMS(Right Management Server)整合等多项功能，并且能实现基于文档和记录条目的授权机制。这里面另外一个比较有特点的机制就是基于站点的两层recycle bin机制防止文档的误删除。

   Web内容管理(Web Content Management)实际上在SPS 2003中就已经很出色，多数企业选择SPS 2003就是因为其强大的Web内容管理功能。在MOSS 2007中在这方面也有很大的增强，用户可以订制站点的导航栏、MasterPage、页面的WebPart、页面搜索功能甚至是站点的内容模板、列表的栏的类型等等，其中MasertPage的定义这个功能十分强大，Master Page是ASP.NET中管理站点页面统一布局的机制，在MOSS 2007中同样引入了这个机制，在后面我会单独抽出空间来介绍Masert Page的功能。另外，MOSS同样支持多语言站点，甚至在中文版中提供了一个已经开发好的Workflow专门处理多语言站点的建立。

•    Search Engine(搜索引擎)

    SPS 2003中的搜索引擎虽然可用，但是效果和准确程度让人很不满意，但是在MOSS 2007中提供了一个全新的Search Engine，熟悉2k3的人都知道，2k3的搜索是基于SQL Server的全文索引机制的，而在MOSS 2007中，Search完全是MOSS提供的一项服务，据说Search Service是微软重新开发的一套搜索引擎，效率和准确度方面比2k3有大幅的提升。因为在MOSS 2007中不仅可以对MOSS Sites进行搜索，同样可以对共享文件夹、其他web 站点甚至是自定义的文档类型进行搜索(对自定义文档类型搜索需要开发支持)，因此微软居然把MOSS 2007的Search单独拿出来作为一个产品来卖，企业可以仅买Search这一个功能。从这个角度看，微软对Search这个功能还是很有信心的。Search Engine甚至可以透过BDC(Business Data Catalog,MOSS 中最重要的一个服务，后面单独介绍)对SAP、PS等其他企业应用的数据进行Search。

•     InforPath Forms Services

     InforPath Forms Services实际上实现了一个基于Web的Form Server，即使客户端没有安装InforPath同样可以通过访问MOSS提供的InforPath Forms Services实现表单的数据收集，这为企业的实现数据采集和流程审批提供了坚实的基础，前面提到过，Office 2007的文档格式是完全开放的XML，因此Office Document的中的数据格式具有较好的完整性，支持XML的扩展数据写入，基于这项功能，完全可以开发个性化的InforPath Form并发布到服务器上供用户通过Web访问该Form并提交数据。

•     Excel Services

    Excel Services为MOSS 2007添加了一个BI前端的功能，Excel Services的功能和InforPath Forms Services类似，实现了一个基于Web的Excel Server，发布到Excel Services上的Excel文件不仅可以保持原有的数据，甚至连运算逻辑都可以保留，更让人兴奋的是所有的运算逻辑居然可以以Web Service的形式访问，这为企业内部的数据逻辑发布与管理提供了比较好的实现手段。基于Excel Services完全可以定义出一个企业BI的前端，反映关键的业务数据和KPI。

•     Business Data Catalog(BDC)

    Business Data Catalog的确不太好翻译成中文，权且使用简称BDC就不翻译吧。BDC是MOSS 2007中提供的一个便于实现的将后台应用数据提取并展现到MOSS中的一个功能，实际上类似于Biztalk中的Adapter，但是在功能和性能方面不如Biztalk强大，不过对于MOSS来说有这样的一个功能足可以填补企业应用整合(EAI)方面很大的空缺了。透过BDC，可以在MOSS 的Site中显示来自于其他业务应用的数据，可以是企业的ERP、CRM、HR等应用中的数据库，DBMS的类型也可以不是SQL Server，从微软的技术角度来讲支持一切数据源数据的显示(当然了需要一定的开发工作),不过据说国外的好多公司已经开发出来透过BDC从SAP等Server中提取数据的配置文件。透过BDC，MOSS可以将后端业务数据显示在Webpart、List中，可以在站点的Event中使用来自于BDC的数据、可以在Search中BDC的数据、可以通过BDC获得User Profile。从MOSS自身的角度讲BDC大大提高了MOSS的平台能力。

•     Workflow

    基于.NET Framework 3.0的Workflow作为MOSS 2007中最重要的一个功能组件已经被封装到MOSS的底层服务中，在MOSS 2007中无处不见Workflow的身影。在MOSS 2007中有三种方式创建工作流：MOSS的默认站点定义中提供了已经开发好的几个工作流程、使用Sharepint Designer可以配置更为复杂的工作流并直接发布到MOSS的站点中、完全基于Vs.net开发的自定义工作流。有了以上三种方式，可以满足不同层次用户对工作流的需求。

    以上从几个方面简单介绍了MOSS的一些新的功能和概念，但是介绍的很概括，关于每一个概念和功能我在今后一段时间内会逐项的进行详细介绍，包括安装、配置、管理、开发、部署等内容。

   之所以犹豫是担心平时时间比较少,没时间更新这个技术类blog,但是想一想当年写书的时候,其实工作也挺忙,都是利用晚上的时间写,最后一本300多页的书也是写出来了.写blog其实比写书自由多了,写书被限定住了范围,而写blog则可以自由发挥,把自己最近学习的技术,研究的东西都可以放上来写.

   设定一个初级目标,12月31日之前要写8篇技术类blog.看看能不能实现.