如何利用Sharepoint开发一个完全不同与Sharepoint风格的站点，这是这篇文章要讨论的内容。以下是项目的开发步骤：
步骤一：定义基本的网站地图和设计
就像许多Web项目一样，基本的站点地图和设计告诉开发团队基本的功能需求。站点地图能够使我们知道在站点上的各种不同类型的页面，设计使我们知道需要使用什么样的Feature.两者会随着进程不断的变化，但是他们给我们提供了项目开始的基线。
步骤二：定义自己的Content Columns 和Content Types
Content Types 是SharePoint的巨大特色，它为整个站点提供了底层结构。在项目的初期花费时间定义页面布局和Lists所需要的Content types是值得的。不需要定义的特别彻底，但是在开始时在这方面做的工作越多，以后返工的工作就少。
可以在项目中创建若干个Content Type组。例如”HedKandi Page Layout Content Types”和”HedKandi Custom List Content Types”.这主要考虑到当最终用户创建views时有更好的用户体验，同时也可以容易区分哪一个是开箱即用的content types,哪一个是我们创建的。
步骤3：定义自定义Lists
Lists是项目的骨架，可以创建若干个Site Collection级别的Lists以保证一致性和内容的复用。
步骤4：创建基本的站点层次结构
如果站点的层次结构不复杂，那就在Site Action用户界面下创建层次结构。如果是一个相当大的站点，那就应该提前创建整个站点的层次结构，建议使用 Stsadm –o createsite 命令或写一个简单的应用程序通过API自动创建层次结构。
步骤5 加入图像和CSS文件
一旦拥有了基本的站点架构，Custom content types和Lists,就可以开始把站点建造成设计的样子。这是我们第一次使用SharePoint Designer的时候，利用SPD可以非常容易地加入Css文件。至于Content Types如果想确保我们知道哪一些是开箱即用的，哪一些是我们在工程期间加入的，可以在Style Library List中加入新的目录例如叫做HedKandi，在这个目录下分别创建CSS和Images目录，我们把图像和CSS文件分别放到这些目录中。
步骤6 建立自己的Master Pages
因为工程中有许多布局大不相同页面，而且它们位于站点的不同位置，所以选择使用多个Master Pages。由于已经对XHMTL文件做了大量的工作，所以我们可以快速的创建新的Master Pages.因为我们想要利用站点中现有页面布局，所以我们对<asp:ContentPlaceHolder> 控件保持同样的命名规则。
步骤7 创建自己的页面布局
这时我们可以真正看到预定义好的Page Layout Content Types以及XHTML的益处。当做了这些工作后创建一个平面的页面布局是相当快速的，主要是由于SPD的工具箱和SharePoint的高度集成。把content field加入到页面中，只要把它从工具箱中选中，拖拽到页面上就行了，不论是在设计模式还是代码模式下。如果已经很好定义了Content Type并且进行了适当的描述，这样开发人员就不必总是通过参考文档才知道field control是做什么的，这些controls应该是什么格式的，这将在工程中大大节省时间。
这时，我们就拥有了一个可以工作的站点，看起来非常接近设计的样子，可以让作者开始向Lists输入内容，创建基于Page Layouts的页面。这就勾勒出了测试过程，因为这意味着我们能够捕捉到丢失的Fields或功能。
步骤8 定制自己的Content Query webpart 视图
Content Query wb part是在网站中最常用的webpart之一。我们在各处使用它们从Lists中集合内容数据。我们发现为了满足设计上的需要，可以快速的变化web part提供的一套标准的视图。我们可以创建定制的XSLT模版以满足需求，通过修改itemstyle.xsl文件――位于站点集合根目录下的/Style Library/XSL Style Sheets
通过给itemstyle.xsl文件增加一个新的XSLT模版就自动的把其中的内容增加到Web part属性的下拉列表中。这非常省时，但是要注意文件中语法错误会导致在Site Collection中的所有的Content Query webparts实例崩溃。
Additional Work: Page Comments
One of the key requirements for Ministry Of Sound was to allow page level comments on certain types of web content page. To resolve this requirement we turned to the design pattern shown by the Comments functionality in the Blog site template.
In the blog comments example, there are two lists – a Posts list, containing the blog posts themselves, and the Comments list, containing the comments. The Comments list has a column of type “Lookup”, which is configured to use the Posts list as its source. When viewing a blog post, a ListView and ListForm webparts are used to provide a view of the comments and a form to allow users to post new comments. This form automatically populates the lookup column with the correct Post.
We used exactly the same mechanism to provide comments for pages in the HedKandi site, except we used the Pages list instead of the Posts list.
Conclusions
While there was a fairly large learning curve to overcome during this project, the fact that our developers were experienced in both SharePoint and MCMS technologies did reduce the curve dramatically. Working closely with our clients meant that we were able to rapidly develop and deliver the project – in a timescale of weeks rather than months.
We found MOSS itself to be generally stable -- even at Beta 2 -- with only a few quirks here and there. Site creation and configuration were simple (although the menus weren't always intuitive -- we see some training issues ahead for our clients). The integration with wider .NET concepts, such as Windows Workflow Foundation, forms-based authentication, membership and navigation were all very good and very powerful and ultimately proved to be real time-savers. One particular point for this project is that we used ASP.NET's membership provider and migrated all of the existing Hed Kandi registration details into the ASPNET database, and we configured it all to integrate with MOSS in less than a day.