何小碩's profileGet More... ExperiencePhotosBlogListsMore ![]() | Help |
|
March 29 在 Windows Server 2008 上安裝 MOSS 2007安裝過程中需要有幾個前置步驟, 如下:
March 27 SharePoint 2007 Employee Directory Web PartMany of our clients have asked us about some type of function or Web Part that lets them show a list of users in their site collection, specifically from the "Users and Groups" list that they can control. Out of the box MOSS gives you the Site Users Web Part. This is often discarded by the client because it is too basic. Here is what it looks like: We are generally asked if we can show profile pictures, some imported Active Directory profile information, sorting, links to the user display or My Site page. In order to do this we chose to write a custom Web Part. The point of this article is to show SharePoint developers an alternative method to using the Site Users Web Part as an employee directory. We will show the basic steps to create your own Web Part to offer more information and flexibility while introducing you to some SharePoint functionality you may not be familiar with. This article assumes you are familiar with Web Part development in SharePoint 2007 and already understand how to build and deploy a basic Web Part with a basic understanding of ASP.NET development.
The Code and the Process Recently for a client we needed to pull user information from the root Site Collection to create a "Face Book". Since users and permissions are Site Collection-based, this allows the local administrator to manage the list of users that will be visible in the Face Book. We chose to use the SPList SiteUserInfoList to obtain this data. We will go into the details of this list in another post, but for the purposes of this article it is the Site Collection-based user/permissions list. We used the list located at the Site Collection's root Web: The SPList object does not support binding to a DataTable, but a hidden gem in WSS 3.0 is the ability to call SPList.Items.GetDataTable(). This returns an SPList object converted to a DataTable object which can more readily be used with grid controls. We also chose to use the SPGridView instead of the standard GridView from .NET 2.0. The version specific to SharePoint creates default formatting to match standard WSS 3.0 Web Parts. One item on my wish list from this experience would be that an SPList could be bound to an SPGridView natively without requiring the conversion to a DataTable object. In the OnInit() event handler we add to our control tree and this is where we set up all our UI Controls. Below is a snippet of code that shows wiring up a DropDownList to handle filtering by Active Directory department, creating the SPGridView and adding a few different types of columns to the display grid. In the OnLoad() event of the page we simply call the Method to Load the Data. We call this with the SPSecurity.RunWithElevatedPrivileges so that any data accessed with be run with administration privileges. The Bind method looks like this: We iterate through the User DataTable in order to make some changes along the way. SharePoint likes to store some data with delimited values in a single field. It does so with the user's profile picture URL. We have to split this value in order to assign it to an ImageField column. Next it shows the limitation of the UserInformationList. Without going into detail in this article, this data represents a small subset of the Profile Data you might expect to be available at the Site Collection level. In order to get Profile data not available in the local context, we must load a UserProfile object to obtain the Mobile Phone data we needed to display. Not the most elegant solution, but it worked. At this point we assigned the DataView to the DataTable and give a standard RowFilter that removes records from the view that do not contain a last name. This filters out generic accounts as opposed to legitimate Site Collection users. Here is the rest: Next we're checking for a post back and essentially lining up the filtering and sorting so that it maintains state between posts. The only interesting thing to note here was the need to select a distinct value from the UserInformatonList DataTable. The only easy way I found to do it was by calling the DataTable.DefaultView.ToTable() method that allows you select distinct records as a boolean and on what columns. I only needed department because this represented my DropDownList filter. The remaining code represents the event handler methods to control sorting and filtering. This is the same in SharePoint as it is in ASP.NET, so I don't think I need to post it. Below is roughly how the Web Part looks rendered: I don't have a lot of users in this Site Collection, but you get the point about what an SPGridView looks like, the user data, picture, DropDownList, and sorting. This should at least serve as a glimpse into what is possible. -Ryan March 16 Writing your own custom DataFormWebPart with C#
I believe that the DataFormWebPart class is a very powerful, often overlooked, piece of functionality available to SharePoint Developers that deserves some serious attention. The DataFormWebPart (DFWP) is nothing new, and many have blogged about creating one through SharePoint designer (SPD), but what I want to discuss is the possibilities that exist when creating one through C# (or VB). The Story… Imagine a WebPart that you can just drop on a page, set some web part properties, and SHAZAM – you’re displaying enterprise data from any source – configurable at RUN TIME. You may be thinking I’m talking about the Business Data Catalog (BDC) that comes with MOSS, and I have to admit, I am. However, what if you don’t feel like paying for MOSS and you still want similar functionality? Even for people that have MOSS – the DFWP is still a great means to get data on the page with minimal effort, and you can take advantage of the sorting, grouping, and filtering functionality that comes with the DFWP – saving coding time. In this post, I am going to cover 1. Demonstrate how to bind the DFWP to XML returned from a web service through C# - rather than through SPD. 2. Tips to help you with your DFWP’s XSL 3. Real world scenarios why this is a great idea. What to think about when overriding… In my opinion, there are only 2 main components to the DFWP that a developer needs to think about, the Data Source, and the XSL that is used to format that data. I started by creating a new class that inherits from Microsoft.SharePoint.WebPartPages.DataFormWebPart. Then, I overrode the OnInit method in my web part. At a minimum, there are only 2 properties you will have to set to get your DFWP to work, the DataSourcesString or DataSource(s) properties, along with the XslLink or the Xsl properties. Following the setting of these properties you would call the DataBind method and you’ll be done: However, if this is all you do, you might as well just use SPD because you haven’t gained anything. The thing to keep in mind here is that we want to set our data sources at run time, giving our end users the ability to target any data they desire. The DataSource property accepts an IDataSource object. A good example of an appropriate object here would be to use the SqlDataSource object that is bound to a SQL stored procedure. As long as the procedure returns the Data in a format that your XSL expects, this is a great option. I however chose to get my data through a web service (simply to comply with company standards). You see the DataSourcesString that I used above, that is basically a string that contains the SOAP envelope and the location and name of my web service. In that string there are 6 web service settings that need to be set. Example of these settings: Here’s the string in its entirety: A great tip that makes this web part very dynamic is to create a web part property for each of these settings. That way, the user can just drop the DFWP on the page, set the properties, and they’ll be off to the races. Additionally, I check the Form Post and the Query String for the variables, giving my users and developers 3 options to get these settings set. Tips for your Xsl… The best way to build your Xsl for your new DFWP is to let SPD do it for you. This won’t work unfortunately if you want to bind to a SQL data source because that is disabled in SPD, so you’ll have to start with my code. Once you have the Xsl, you can either put it in a file on a URL and set the “XslLink” property, or you can set the Xsl string itself to the “Xsl” property. I do the latter by putting my Xsl file as an embedded resource in my assembly. I do this simply because it makes deploying easier. If you do find yourself playing in the Xsl, there’s one area that is particularly worth mentioning. In the “dvt_1.body” template – there’s a line as follows: This variable “Rows” is set to the response to the “ReturnJobStatus” web service method. You will need to alter this to reflect your web service method name. A better way to do this would be to get this variable from the query string, and then the web part would be more generic. If you examine the above line carefully – you should know that the expected format of the XML is of the following raw format: You can change this to another format by altering the “/Rows/row” in the variable assignment. Rows-Row is the default configuration that SPD expects to see when it tries to generate the DFWP. If the xml is not in this configuration – SPD will error out when you try to add the DFWP into a zone. Here’s a screen shot of my DFWP in action: In summary, why this is cool… By writing your own DFWP – the sky is the limit as to how far you can customize and reuse the DFWP’s functionality. Imagine a business that requires your end users to be able toggle the data sources of your DFWP at run time. All you would have to do is override CreateChildControls and add three buttons to your DFWP. When the user clicks each button, you could toggle the DFWP to another data source. Try doing that with SPD (without writing 3 DFWP’s that is)! Please email me at - phil [dot] wicklund [at] mindsharp [dot] com - if you would like the source. Phil Wicklund March 13 Alert 沒辦法運作??第一種解決方式: 出現以下錯誤: UnKnown Error Troubleshoot issues with Windows SharePoint Services
stsadm -o updatealerttemplates -url http://portalnamehere -filename "C:\Program files\common files\Microsoft shared\web server extensions\12\template\XML\alerttemplates.xml" 第二種解決方式: Please check the following: 1. Are you receving a confirmation that you've got subscribed for the alerts ? 2. Alerts are based on SMTP, check whether you have configured the proper SMTP server and check whether MOSS 2007 server has access to SMTP server 3. If you have anti-virus software on the server, check whether it is blocking the bulk mail functionality, becuase alerts are going to be sent as bulk mails 4. Please check whether the events are turned-on the MOSS 2007 server, else explicity the turn on the events in the server 5.Please check whether the following tables in MOSS 2007 database have entries related to your alerts EventLog table EventCache table SchedSubscription table ImmedSubscription table 6. Verify all of your accounts (Service LOG ON accounts, APP Pool accounts and DataBase accounts) whether it has proper access 7. Verify whether the indexing and Crawling has happened properly. 8. Check the gatherer log and see whether there are any errors Please update me after all the checks As far as i know, there is no way to turn-off/turn-off/re-start the alerts at Site Collection level 第三種解決方式:(For Document Library) Problem: Alerts on document libraries in MOSS work for portal administrators, but not for regular users. Regular users do receive the email notifying them that their alert has been set up. Information: This was only happening on sites created with custom site definitions. Testing showed that the 'approval' permission could be added to the Members or other group of the site and alerts would then work for those users, but that is not a good solution for most environments. Solution: Not a pretty one, but the best that Microsoft could come up with.
March 08 研討會: Microsoft Office SharePoint Server 2007 建構高科技業知識管理網站-理論與實務2008年3月12日 下午 01:30 - 2008年3月12日 下午 04:30 台北 台灣微軟 7A/7B 台灣 台北 台北市松仁路7號7樓 語言:中文. 產品:SharePoint Portal Server. 適用對象:IT 專業人員, 資訊決策者 和 開發人員. 活動概觀
說明: PS: 此次的研討會主要是以經驗分享為最主要的主軸哦~~ 這次研討會我這邊將會和竹科某公司的資訊部門經理來做這一次經驗上面的分享,其內容包含了:
使用 MSN 帳號密碼登入後即可 線上登記 March 07 FIX: 錯誤訊息當您在 SQL Server 2005 Reporting Services 中報表檢視器 Web 部分顯示參數化的報表: 「 物件 」 不是設定為執行個體的物件參考重要:本文是以 Microsoft 機器翻譯軟體翻譯而成,而非使用人工翻譯而成。Microsoft 同時提供使用者人工翻譯及機器翻譯兩個版本的文章,讓使用者可以依其使用語言使用知識庫中的所有文章。但是,機器翻譯的文章可能不盡完美。這些文章中也可能出現拼字、語意或文法上的錯誤,就像外國人在使用本國語言時可能發生的錯誤。Microsoft 不為內容的翻譯錯誤或客戶對該內容的使用所產生的任何錯誤或損害負責。Microsoft也同時將不斷地就機器翻譯軟體進行更新。如果您發現錯誤,並想要協助我們進行改善,請填寫本篇文章下方的問卷。 文章編號 上次校閱 版次 錯誤: #50001812 Hotfix (SQL) Microsoft 發佈 Microsoft SQL Server 2005 修正程式為一可下載的檔案。 修正程式是累積性, 因為每個新版本包含所有 Hotfix 並修正所有安全性修正程式, 都包含在前一個 SQL Server 2005 版本。 徵狀請考慮下列情況: • • • • • • • • • • • 當您指定參數而非預設參數, 並按一下 [ 套用 ] 以使用新的參數來顯示報告, 會收到下列錯誤訊息: 物件參考未設定至物件的執行個體. 發生的原因這個問題的發生原因, 因為當您指定在報表檢視器 Web 部分參數如果 Web 組件是連結至文件庫清單網頁組件為 NULL 參考例外狀況發生。 解決方案針對此問題修正程式第一次發行累積更新 4 中。 如需如何取得這項累積更新程式套件適用於 SQL Server 2005 Service Pack 2, 請按一下下列文件編號, 檢視 「 Microsoft 知識庫 」 中的文件中的文件: 941450 (http://support.microsoft.com/kb/941450/LN/) 用於 SQL Server 2005 Service Pack 2 4 累積更新程式套件 請注意 , 因為組建是累積性, 每個新修正版本包含所有 Hotfix 並修正所有安全性修正程式, 都包含在前一個 SQL Server 2005 版本。 Microsoft 建議您考慮套用修正程式最新版本包含此 Hotfix。 如需詳細資訊,請按一下下面的文件編號,檢視「Microsoft 知識庫」中的文件:: 937137 (http://support.microsoft.com/kb/937137/LN/) 建置所發行的 SQL Server 2005 Service Pack 2 發行後, SQL Server 2005 Microsoft SQL Server 2005 Hotfix 是專為某些特定的 SQL Server Service Pack 而建立。. 您必須套用至的 SQL Server 2005 Service Pack 2 安裝 SQL Server 2005 Service Pack 2 Hotfix。 根據預設,某一版 SQL Server Service Pack 所提供的任何 Hotfix 都會包含在下一版的 SQL Server Service Pack 中。. 狀況說明Microsoft 已確認本篇文章<適用於>一節所列之 Microsoft 產品確實有上述問題。. 其他相關資訊如需哪些檔案會變更, 以及想瞭解有關要套用累積更新程式套件包含 Hotfix, 此 Microsoft 知識庫 」 文件中所描述的任何必要的資訊請按一下下列文件編號, 檢視 「 Microsoft 知識庫 」 中的文件中的文件: 941450 (http://support.microsoft.com/kb/941450/LN/) 用於 SQL Server 2005 Service Pack 2 4 累積更新程式套件 March 01 Business Intelligence Demos( From Microsoft )
|
|
|