Posts Tagged ‘MOSS’

Use Custom CSS in MOSS RadEditor

November 17th, 2009 Comments off

Telerik’s MOSS RadEditor is a great editor, especially if you are concerned about accessible html outputs. If you are using MOSS RadEditor, you might notice that it doesn’t pick your custom styles at edit time. Reason is by default it uses this style file “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\wpresources\RadEditorSharePoint\\RadControls\Editor\Skins\Default2006\EditorContentArea.css”. You have two options one you can edit this file and add your style here.

Second option is that you can set the css file by using the property “CssFiles” in ConfigFile.xml or ListConfigFile.xml depends on your configuration. For example you are deploying your CSS files in below folder structure under layouts folder.


your entry in config files will be like this.

<property name=CssFiles><item>/_LAYOUTS/MyWebFiles/css/editor_style.css</item></property>


Categories: MOSS Tags: , , ,

Using SharePoint site Navigation to a non-SharePoint website

October 5th, 2009 Comments off

It was a very interesting task we had from one client. We had developed a publishing internet site for the same client. This client has a non SharePoint site, somehow this non SharePoint site has a relation with SharePoint site and client wanted to provide an option to navigate to other site from publishing SharePoint site. The interesting thing was client wanted to have the same look and feel for other site as of SharePoint site, specially client wanted to have the same left navigation. So when users navigate from SharePoint site to non SharePoint site they don’t get the feeling that now they are on a different website.

We have tried to think in different ways to implement this option. But there was no straight forward way to use the SharePoint navigation in a non SharePoint site. After giving it some thought we suggested something pretty simple, which looked difficult in initial talks.

We have created a web service, which interact with SharePoint. This web service actually makes a request to the same page from SharePoint website, from where we have to use the left navigation. Then it grab the whole html and use xpath to extract the div with navigation part. It just return this extracted html as xml.
Now we call this web service from the non SharePoint website and fill the left part with returned div from web method used in web service. It seems pretty simple 
We used the same technique to change the whole look and feel for the non SharePoint site to match the SharePoint site. And it worked great.

Here is the piece of code from web service.

[WebMethod(Description = "pageType should be one of pre-defined page type.")]

public XmlDocument GetLeftNavigation(string pageType)


  XmlDocument oDoc = new XmlDocument();


  string html = “”;

  if (ConfigurationManager.AppSettings[pageType] != null)


    string url = ConfigurationManager.AppSettings[pageType];

    HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);

    request.Method = “GET”;

    request.Credentials = CredentialCache.DefaultCredentials;

    HttpWebResponse response = (HttpWebResponse)request.GetResponse();




      if (response.StatusCode == HttpStatusCode.OK)


        // get the response stream.

        Stream responseStream = response.GetResponseStream();

        // use a stream reader that understands UTF8

        StreamReader reader = new StreamReader(responseStream, Encoding.UTF8);



          html = reader.ReadToEnd();

          html = html.Substring(html.IndexOf(“<div id=\”nav-y\”>”));

          html = html.Remove(html.IndexOf(“</li></ul></div>”) + 16);


          if (oDoc.GetElementsByTagName(“a”).Count > 0)


            string siteUrl = ConfigurationManager.AppSettings["webpath"];

            foreach (XmlNode oNode in oDoc.GetElementsByTagName(“a”))


              string href = oNode.Attributes["href"].Value;

              href = siteUrl + href.Substring(1);

              oNode.Attributes["href"].Value = href;




        catch (Exception ex) { }



          // close the reader










  return oDoc;


Hope you will like it.


Categories: MOSS Tags: , ,

SPList Bits and Pieces

August 19th, 2009 1 comment

Recently I have gone through a very informative white paper on Sharepoint SPList. I’m impressed with the deep knowledge of the author. I have this white paper with me and it’s a word document on 22 pages. I have summarized some important information from it. Hope you will enjoy it.

Maximum number of items in SPList

You might read on internet that SPList can contain maximum 2000 elements. First of all it’s definitely wrong. The maximum number of items supported in a list with recursive folders is 5 million items.
There is a limit of 2000 items, but it is for each container. You can think of container as a root folder for items. Without any folder in a list, list itself will be a container for items. So you can have 2000 items in a list without any folder. But if you create folders and sub folders then you can have millions of items in a list.
This limit is because of standard Sharepoint UI, if you have your own UI you can cross this limit of 2000 items.

Data access methods

There are eight different methods to access data from SPList. This figure is interested, I also had no idea about all the methods.

  • Browser
    The list was viewed using a browser and the predefined Office SharePoint Server 2007 interface.
  • SPList with For/Each
    This is we normally use by looping through SPListItemCollection of SPList.Items.
  • SPList with SPQuery
    The OM was used to create an SPQuery object that contained the query criteria. That object was then used to against an instance of the list in a SPList object. The results of the query were returned by calling the GetItems method on the SPList object.
    SPList.GetItems (SPQuery)
  • Browser
    In this case an instance of the list is obtained with an SPList object. The data from it is then retrieved into a DataTable by calling the GetDataTable() method on the Items property —for example, SPList.Items.GetDataTable(). The DataTable’s DefaultView has a property called RowFilter that was then set to find the items.
    SPListItemCollection.GetDataTable ()
  • SPListItems with DataTable
    This method is similar to the SPList with DataTable method, but with a twist. An instance of the list is retrieved through an SPList object. An SPQuery object is created to build a query, and that query is executed against the SPList object, which returns an SPListItems collection. The data from that collection is then retrieved into a DataTable by using the GetDataTable() method on the SPListItems collection.
  • Lists Web service
    The Lists Web service, which comes with Windows SharePoint Services 3.0 and Office SharePoint Server 2007, was used to retrieve the data. A Collaborative Application Markup Language (CAML) query was created and submitted along with the list identifier, and an XML result set was returned from the Lists Web service.
  • Search Object Model
    The search object model was used to execute a query against the Office SharePoint Server 2007 search engine and return the results as a ResultTableCollection. In order to use search for SPList, you need to create managed properties and perfrorm indexing on them.
  • PortalSiteMapProvider
    One approach to retrieving list data in Office SharePoint Server 2007 that’s not very well known is the use of the PortalSiteMapProvider class. It was originally created to help cache content for navigation. However, it also provides a nice automatic caching infrastructure for retrieving list data. The class includes a method called GetCachedListItemsByQuery. This method first retrieves data from a list based on a SPQuery object that is provided as a parameter to the method call. The method then looks in its cache to see if the items already exist. If they do, the method returns the cached results, and if not, it queries the list, stores the results in cache and returns them from the method call.
    This looks something very interesting to use.

Query data from large list

I have always find people in trouble when accessing large lists in Sharepoint. They always complaint that Sharepoint lists are very slow in accessing data. Actually it’s all about how you access data from SPList. We have just noticed that there are eight ways to access data from SPList. Now before using any of the option you have to see which one is more suitable in your system.

  • Methods shouldn’t use when accessing large lists
    • Browser View
    • SPList with For/Each
    • SPList with DataTable
  • Fastest methods to query large lists in WSS
    • SPList with SPQuery
    • Lists Web Service
    • SPListItems with DataTable
  • Fastest methods to query large lists in MOSS
    • PortalSiteMapProvider
    • Search API
    • SPListItems with DataTable (it seems even faster to search API, if the number of items in the list are not too much, say for 1500 items it’s a better option.)

Search performed well across all of the scenarios. One drawback to using Search is that it cannot retrieve data until indexing has completed, so if immediate data retrieval is a requirement, Search may not be the best choice. You might need to configure Managed properties.
The PortalSiteMapProvider class was one of the best performing data access methods in every scenario. However, there are a couple of limitations in using it. First, because of the way in which the data is cached, use of the PortalSiteMapProvider class is going to be most useful if the data you are retrieving is not significantly different over time. If you are trying to frequently retrieve different data sets, the PortalSiteMapProvider class will incur the overhead of constantly reading from the database, inserting data into the cache and then returning it from the method call. Clearly, the advantage of the PortalSiteMapProvider class is when it can read data directly from the cache.
Using the SPList class gives you several options to retrieve data — a For/Each enumeration, the Items collection, the GetDataTable method of an SPListItems collection, and using an SPQuery object to filter data. Some of those methods, specifically the GetListItems and GetDataTable from the results of GetListItems, routinely performed well in most scenarios. However, there are some limitations. For example, the GetListItems method won’t work across folders in a single list unless the ViewAttributes property of your SPQuery query class includes Scope=”Recursive”. For that matter, it won’t work across lists if you want to query data from multiple lists or subsites. It also requires that all code runs directly on the Office SharePoint Server 2007 computer. Other options, like the Lists Web service and the Search Web service can retrieve the data but run on remote servers.

Data maintenance considerations

There are a few other issues to consider when creating lists with more than 2,000 items per container. One is the cost of other common operations such as adding or deleting items from the list. Performance for deleting items degrades significantly when a list becomes very large. Deleting a single item from a very large list takes much more time than deleting an item from a smaller list.

Data locking

Another important consideration when using large lists is the concept of the locks that Microsoft SQL Server™ places on data tables that contain list information. Virtually all data for all Office SharePoint Server 2007 lists is contained within a single table in SQL Server. This table contains data for all the lists in all the site collections whose data is stored in that content database. When you attempt to update data on a list item, whether that is adding, editing or deleting a list item, SQL Server will attempt to lock other items (rows to SQL Server) for that particular list.
However, there is a limit to the number of individual rows that SQL Server will try to lock down. If you try to select approximately 5,000 items or more simultaneously for reading or update, SQL Server will typically lock the entire table for the duration of that change. In this event, all other reads and writes for all lists in all site collections are queued until the previous transaction is complete and the lock is released. If your query retrieves data across multiple folders within the list, the locking behavior occurs whether or not list items are recursively nested so that there are not more than 2,000 items in an individual container. To ensure that you don’t encounter this locking behavior, make sure the number of items you retrieve in a single request is well below this threshold. For example, you can control the number of records returned by setting the RowLimit on the SPQuery class.
Crawl times

Another consideration with very large lists is crawl time and crawl time-outs. As a list gets larger, the chances of the indexer timing out when crawling the contents of that list increases. If the indexer is timing out when crawling large lists, you can increase the time-out value with the following steps:

  1. In Central Administration, on the Application Management tab, in the Search section, click Manage search service.
  2. On the Manage Search Service page, in the Farm-Level Search Settings section, click Farm-level search settings.
  3. In the Timeout Settings section, in the Connection time and Request acknowledgement time boxes, enter the desired number of seconds.

I will try to add word file or post the URL of white paper for more information.

Have fun .

Categories: MOSS Tags: ,

Role of DynamicChildLimit in MOSS Navigation

June 2nd, 2009 59 comments

Recently, we were working on a project where pages libraries has hundreds of pages. We have noticed that in left navigation and on modify navigation pages, it was not showing all the pages. Actually, MOSS navigation site map providers returned 50 items by default. if you want to see all the pages, you need to set the PortalSiteMapProvider property of DynamicChildLimit = 0 in web.config.

It will be like this

<add name=”CurrentNavSiteMapProvider” description=”CMS provider for Current navigation” type=”Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapProvider, Microsoft.SharePoint.Publishing, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c” NavigationType=”Current” EncodeOutput=”true” DynamicChildLimit=”0″ IncludePages=”PerWeb” IncludeHeadings=”true” IncludeAuthoredLinks=”true” />


Referenced from Chris Richard’s blogs Increased performance for MOSS apps and MOSS Navigation Deep-Dive .

Categories: MOSS Tags: , ,