[Home] [Recent] [Site Map] [SharePoint] [XBOX]
For each solution we develop for our customers we reuse a set of internal components we have developed – a kind of baseline library. As we use it we fix some errors and add some new functionality. To distinguish the different releases we modify the version of the assembly containing all the logic and the feature version as well. While working on several projects at the same with different project teams we found it quite difficult to check the assembly version each time you want to be sure you are using the latest version. That’s when I have decided to modify the page displaying Site and Site Collection feature and extend it with displaying the version of each feature stored within the feature.xml file.

First of all I have found out that one and the same page is being used for both Site and Site Collection Features. After a little research on the ManageFeatures.aspx page I have found that the task of displaying the list of features is contained within a separate control: FeatureActivator.ascx residing in 12\CONTROLTEMPLATES.
To obtain the version for each feature I have created the following method:
To be able to use this method within the control I have added a reference to my assembly at the top of the control:
<%@ Assembly Name="Imtech.SharePoint.WSSGUI, Version=1.0.0.0, Culture=neutral, PublicKeyToken=token" %>
Finally I have added a reference to my method at the end of the row displaying the Feature title:
<%# Imtech.SharePoint.WSSGUI.Common.GetFeatureVersionById(DataBinder.Eval(Container.DataItem, "FeatureId", ""), Page.Request.QueryString["Scope"])%>
Because there are two item templates you need to add the line above in the AlternatingItemTemplate section as well.
As I have just modified modify an out-of-the-box SharePoint control I have decided to incorporate my changes in a copy of it instead replacing the existing one. It’s not such a good idea to modify SharePoint files: they might be replaced by SharePoint hotfixes, updates, service packs or any other features. Therefore it is recommended to use your own copies of the files you edit.
To make use of my copied and extended control I had to copy the ManageFeatures.aspx page as well and replace the reference to the control with the one I’ve just modified:
<%@ Register TagPrefix="wssuc" TagName="FeatureActivator" src="~/_controltemplates/ImtechFeatureActivator.ascx" %>
Then I have spotted another challenge: I had to replace the links to the Site Features and Site Collection Features on the Site Settings page with a reference to the ImtechManageFeatures.aspx:
The menus on the Site Settings page are created, just like the Site Action menu using the CustomAction element in an Element Manifest. These menus are created using the SiteSettings feature. In the SiteSettings.xml you can find all of the items showed on the Site Settings page. These two actions are ManageSiteFeatures and ManageSiteCollectionFeatures. To replace the Urls of these links, I had to hide them and create my own copies with the correct link. You hide the items as follows:
<HideCustomAction HideActionId="ManageSiteFeatures"And then add your copy:
<CustomActionUrl="_layouts/ImtechManageFeatures.aspx?Scope=Site" />
</CustomAction>
To make it all work you have to first modify the id’s (they have to be unique) and make the links point to the modified version of the ManageFeatures.aspx application page. To wrap it all up you could put it all in a Solution which deploys this Feature. Upon activating it the links will be altered and you will be able to use the extended functionality.
Having access to the features’ version works pretty well for me – especially in dynamic environments with new releases on regular basis. You could take this concept even further and extend it with your own properties that your development team uses. While using my customized Site (Collection) Features page I have discovered that there are a few more pages (like DeactivateFeature.aspx) which link the original ManagaFeatures.aspx. To make the user experience complete you could research these pages and make them reference your extended copy. Let me know if you would like to get this extension as a Solution (.wsp).
I have been working on a new web part that aggregates content of a specific content type into a gridview. Much like the Content Query web part, but easier to use by end-users. They just need to select the content type and the columns they want to be displayed (that’s why I called it “Content by Type”).
The most important features are:
– Works in WSS and MOSS
– Casting / formatting of column data types
– Links to items and its context in contextmenu
– Links to lookup / person fields
– Filter items using MOSS filter web parts
– Supports grouping/sorting and paging
![]()
The screenshot above shows the Content By Type webpart in action. The view displays 4 columns of this content type. The view is grouped by content type and sorted by Modified date. When configuring the webpart, users simply choose a content type and the web part lets them pick the columns they want. The screenshot below shows part of the configuration. Users can (un)select the available content type fields and configure the links for these fields. After configuring the other web part properties (scope, grouping, sorting, list type, etc.) the web part will query for items that match the selected content type(s) and display the results in a grid.
Below you will find a brief description of the most important features. The webpart is currently in beta. I am looking for a number of people that seriously want to help me out testing the webpart. Besides bug reports I am looking for general feedback on how the webparts works and what could/should be improved. If you are still interested after reading the features, please contact me through my weblog. I will then send you the bits and the installation instructions.
PLATFORM
The Content by Type web part works on both Windows SharePoint Services 3.0 and Office SharePoint Server 2007. This introduces content aggregation to WSS sites. The out of the box Content Query webpart is only available in Office SharePoint Server.
Technical info: Before querying the web part decides if it is running in a WSS or a MOSS site. If the feature called “Office SharePoint Server Publishing Infrastructure” is activated for the site collection, it is considered to be a MOSS site. In that case the CrossListQueryCache object is used to query. In WSS sites, the SPSiteDataQuery object is used.
FORMATTING
Data returned by the Content by Type webpart is casted and formatted as the datatype of the column. The formatting options that are applied to the site columns (currency, number of decimals, datetime format, etc.) are also applied to the query results. SharePoint items displayed by the Content by Type web part therefore look the same as items displayed by the SharePoint views. Casting the data to the correct datatype is also important for sorting. This ensures that when a user clicks a column header of a datetime field that the data is sorted like a date.
ITEM LINKS
For every list item returned by the Content By Type webpart, 3 links are automatically generated. While configuring the webpart, these links can be recognized by a ‘(*)’ in the displayname of the fields in the user interface. These links can be displayed on every field. These links are availble:
• Link to item – a link to the details page of the item/document. This is especially useful for documents. SharePoint normally automatically renders the link to the document itself. Getting to the information stored in the metadata of the document is now easy by using the “Link to item” field.
• Link to item (with menu) – a link to the details pageof the item/document with a dropdown menu: 
These menu options can be used to navigate directly to the site or the list that contains the item or document. This makes it much easier for users to get an idea of the context in which the item was published.
• Name Link – a link to the document itself (only available in content types with a “File” column (eg document content types).
LOOKUP AND PERSON OR GROUP FIELDS
If the content type contains Lookup or Person or Group columns, the content by type webpart automatically adds a “linkfield” to the list of available fields. When selecting columns to be displayed, the user can choose to select a link for these fields.
When the items are displayed, these columns now have a link to the person/group or the lookup item. This also applies to the out of the box Modified By and Created By fields.
FILTERING
Office SharePoint Server offers a set of different filter webparts. They all can provide filter values available from different sources to other web parts. The Content by Type webpart supports incoming filters from these filter web parts. In the screenshot below the user has selected “Americas” in the choice filter. This SharePoint filter web part is connected to the Content by Type web part, filtering the Region field.![]()
When connecting the filter web part to Content by Type, you can select the content type field on which you want to filter. The can be any field of the content type, not necessarily a field that is displayed in the grid. When you connect a multivalued filter webpart, all values are handled as an “OR” in the CAML query.
Please note: In the first release filters are limited to MOSS, because of the absense of filter webparts in WSS. The other limitation for now is that you can only connect 1 filter webpart.
PAGING
When configuring the web part, users can set up the maximum number of items that will be returned by the web part. They can also edit the pagesize.

GROUPING AND SORTING
The Content by Type webpart supports grouping and sorting. When configuring the webpart, users can select a field to group by. They also can select the initial sort field and sort order. The sort order can be changed by clicking the column headers.
I was searching in google the past few days looking for Key Business Roles in /folder/sharepoint.htm. For example, do you need developers, admins, project managers, etc... What defines the responsibilities of these people? I started writing on a wiki on my companies /folder/sharepoint.htm Site and I figured out these people are at least needed:
I am going to work on role definitions in the next few days and post them. I would love to hear your comments and maybe some suggestions or changes in these Business Roles for /folder/sharepoint.htm.
Site List:
>>Xbox Live_s Major Nelson
>>Xbox 360 & SharePoint 2007 Weblog
>>Carsten Keutmann_s Blog
>>Mohamed Zaki_s Blog [Sharepoint MVP]
>>The Mit_s Blog
>>Mart Muller_s Sharepoint Weblog
>>Microsoft SharePoint Products and Technologies Team Blog
>>SharePoint Solutions Blog
>>4GuysFromRolla.com Headlines
>>ASP.NET Blogs
>>SharePoint Blogs
>>SharePoint Blogs
>>Joel on Software
>>ADO Guy_s Rants and Raves
>>Microsoft Live Labs
>>GadgetNews
>>Windows Vista Team Blog
>>VoIP & Gadgets Blog
>>schrankmonster blog
>>Via Virtual Earth Blog
>>Feed
>>MSDN Blogs
>>Mashable!
Links:
Jack's Readings
Month Archives:
Oct 2007
Sep 2007
Top Tags:
social software social networking .NET mashable Sharepoint ASP.NET Web 2.0 Web2.0 Startups Community News Search Marketplace General Software Development AJAX Windows Vista Visual Studio Microsoft myspace Silverlight People Powered! YouTube Vista MOSS Featured News C# Events MOSS 2007 Google WPF Office 2007 Web Community Security General Personal Xbox 360 facebook Tools development SharePoint 2007 Fun Atlas Architecture ASP.NET AJAX myspace codes TheLongTail IIS SQL Server Developers Revenue Sharing Video Pictures WCF Mobile 2.0 Announcements Orcas MIX07 Arcade Team System JavaScript News
@2007 All rights Reserved |