如何利用Sharepoint開(kāi)發(fā)一個(gè)完全不同與Sharepoint風(fēng)格的站點(diǎn)，這是這篇文章要討論的內(nèi)容。以下是項(xiàng)目的開(kāi)發(fā)步驟：
步驟一：定義基本的網(wǎng)站地圖和設(shè)計(jì)
就像許多Web項(xiàng)目一樣，基本的站點(diǎn)地圖和設(shè)計(jì)告訴開(kāi)發(fā)團(tuán)隊(duì)基本的功能需求。站點(diǎn)地圖能夠使我們知道在站點(diǎn)上的各種不同類型的頁(yè)面，設(shè)計(jì)使我們知道需要使用什么樣的Feature.兩者會(huì)隨著進(jìn)程不斷的變化，但是他們給我們提供了項(xiàng)目開(kāi)始的基線。
步驟二：定義自己的Content Columns 和Content Types
Content Types 是SharePoint的巨大特色，它為整個(gè)站點(diǎn)提供了底層結(jié)構(gòu)。在項(xiàng)目的初期花費(fèi)時(shí)間定義頁(yè)面布局和Lists所需要的Content types是值得的。不需要定義的特別徹底，但是在開(kāi)始時(shí)在這方面做的工作越多，以后返工的工作就少。
可以在項(xiàng)目中創(chuàng)建若干個(gè)Content Type組。例如”HedKandi Page Layout Content Types”和”HedKandi Custom List Content Types”.這主要考慮到當(dāng)最終用戶創(chuàng)建views時(shí)有更好的用戶體驗(yàn)，同時(shí)也可以容易區(qū)分哪一個(gè)是開(kāi)箱即用的content types,哪一個(gè)是我們創(chuàng)建的。
步驟3：定義自定義Lists
Lists是項(xiàng)目的骨架，可以創(chuàng)建若干個(gè)Site Collection級(jí)別的Lists以保證一致性和內(nèi)容的復(fù)用。
步驟4：創(chuàng)建基本的站點(diǎn)層次結(jié)構(gòu)
如果站點(diǎn)的層次結(jié)構(gòu)不復(fù)雜，那就在Site Action用戶界面下創(chuàng)建層次結(jié)構(gòu)。如果是一個(gè)相當(dāng)大的站點(diǎn)，那就應(yīng)該提前創(chuàng)建整個(gè)站點(diǎn)的層次結(jié)構(gòu)，建議使用 Stsadm –o createsite 命令或?qū)懸粋€(gè)簡(jiǎn)單的應(yīng)用程序通過(guò)API自動(dòng)創(chuàng)建層次結(jié)構(gòu)。
步驟5 加入圖像和CSS文件
一旦擁有了基本的站點(diǎn)架構(gòu)，Custom content types和Lists,就可以開(kāi)始把站點(diǎn)建造成設(shè)計(jì)的樣子。這是我們第一次使用SharePoint Designer的時(shí)候，利用SPD可以非常容易地加入Css文件。至于Content Types如果想確保我們知道哪一些是開(kāi)箱即用的，哪一些是我們?cè)诠こ唐陂g加入的，可以在Style Library List中加入新的目錄例如叫做HedKandi，在這個(gè)目錄下分別創(chuàng)建CSS和Images目錄，我們把圖像和CSS文件分別放到這些目錄中。
步驟6 建立自己的Master Pages
因?yàn)楣こ讨杏性S多布局大不相同頁(yè)面，而且它們位于站點(diǎn)的不同位置，所以選擇使用多個(gè)Master Pages。由于已經(jīng)對(duì)XHMTL文件做了大量的工作，所以我們可以快速的創(chuàng)建新的Master Pages.因?yàn)槲覀兿胍谜军c(diǎn)中現(xiàn)有頁(yè)面布局，所以我們對(duì)<asp:ContentPlaceHolder> 控件保持同樣的命名規(guī)則。
步驟7 創(chuàng)建自己的頁(yè)面布局
這時(shí)我們可以真正看到預(yù)定義好的Page Layout Content Types以及XHTML的益處。當(dāng)做了這些工作后創(chuàng)建一個(gè)平面的頁(yè)面布局是相當(dāng)快速的，主要是由于SPD的工具箱和SharePoint的高度集成。把content field加入到頁(yè)面中，只要把它從工具箱中選中，拖拽到頁(yè)面上就行了，不論是在設(shè)計(jì)模式還是代碼模式下。如果已經(jīng)很好定義了Content Type并且進(jìn)行了適當(dāng)?shù)拿枋?，這樣開(kāi)發(fā)人員就不必總是通過(guò)參考文檔才知道field control是做什么的，這些controls應(yīng)該是什么格式的，這將在工程中大大節(jié)省時(shí)間。
這時(shí)，我們就擁有了一個(gè)可以工作的站點(diǎn)，看起來(lái)非常接近設(shè)計(jì)的樣子，可以讓作者開(kāi)始向Lists輸入內(nèi)容，創(chuàng)建基于Page Layouts的頁(yè)面。這就勾勒出了測(cè)試過(guò)程，因?yàn)檫@意味著我們能夠捕捉到丟失的Fields或功能。
步驟8 定制自己的Content Query webpart 視圖
Content Query wb part是在網(wǎng)站中最常用的webpart之一。我們?cè)诟魈幨褂盟鼈儚?/span>Lists中集合內(nèi)容數(shù)據(jù)。我們發(fā)現(xiàn)為了滿足設(shè)計(jì)上的需要，可以快速的變化web part提供的一套標(biāo)準(zhǔn)的視圖。我們可以創(chuàng)建定制的XSLT模版以滿足需求，通過(guò)修改itemstyle.xsl文件――位于站點(diǎn)集合根目錄下的/Style Library/XSL Style Sheets
通過(guò)給itemstyle.xsl文件增加一個(gè)新的XSLT模版就自動(dòng)的把其中的內(nèi)容增加到Web part屬性的下拉列表中。這非常省時(shí)，但是要注意文件中語(yǔ)法錯(cuò)誤會(huì)導(dǎo)致在Site Collection中的所有的Content Query webparts實(shí)例崩潰。
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.
