SharePoint

Syrinx SharePoint Team Blog
Need help on your project? info@syrinx.com, or toll free (888) 579-7469, press 1

News



Need help with your SharePoint project?

Syrinx works with clients throughout New England and across the United States to architect, design, develop, and deploy SharePoint implementations. Working on fully outsourced projects, as part of your team, helping to train your team, or rescuing projects in trouble, we are comfortable doing it all. Projects from a couple weeks to several months in duration, reference clients available. Contact us today - info@syrinx.com, or toll free (888) 579-7469 and press 1 to speak to someone now!

May 2008 - Posts

MOSS Enterprise Search. Addition to Part 1

In the first part of the series we've looked at how to create content sources to be crawled. In addition to that, you can control the behavior of the crawler on the content sources by setting exclusion and inclusion rules on the content. Those rules apply to all and any content matched by specified URL patterns. Let's take an example: you don't want the indexer to index anything under  http://yourserver.com/sites/ with one exception: you want to index one particular subsite: http://yourserver.com/sites/yourblogs.

First, you need to set an exclusion rule:

  1. Open Shared Services web site:
    • Open Sharepoint 3.0 Central Administration web site
    • Under Shared Services Administration section on the left side navigation, click on the Shared Services link to load Shared Services web site image
  2. In the Search section click on Search Settings link:
    image
  3. In Crawl Settings section click on Crawl Rules link
  4. Now we will create an exclusion rule to exclude all sites and content under http://yourserver.com/sites/ from being indexed:
    1. Click the New Crawl Rule button
      image
      to enter the Add crawl Rule wizard: image
    2. In the Path box enter the URL filter: http://yourserver.com/sites/*, then click Ok button to save the rule.
  5. Next we create an inclusion rule that will allow content of some sites excluded in the previous step to be indexed: as in the previous step, click the New Crawl Rule button, the in the Path text box enter the URL pattern to be included: http://yourserver.com/sites/yourblogs/*, and select Include all items in this path option in the Crawl Configuration section, then click Ok to apply the rule.
Best Practices for Naming Sites and Pages.

A comment I frequently hear is: SharePoint tabs don't always highlight properly.  As it turns out, if you are in the habit of doing things a certain way, they always work.

First, make sure you are turning on "Show Pages" and/or "Show subsites".  You can find this in Site Settings by clicking on Navigation.

Second, when you are adding sites and pages make sure their names don't have spaces.  See my blog on best practices for working with column names for a deeper discussion; I generally extend this to everything I create in SharePoint by habit now and as it turns out why I never run into this problem.

Third, when adding pages or sites to your navigation, always browse to the intended destination; this will ensure your tabs will work properly.  In fact if you compare the resulting URL after you fix a broken tab this way, you will see that the URL must be relative, not absolute.

Following these best practices should prevent the problem where SharePoint (MOSS or WSS) tabs are not highlighting.

-Joe

 

Moving up to find that list

 

I'm going to write a bit about a problem I ran into when I wrote a bulk upload application for one of my SharePoint clients.  I found that when I was importing a document and applying a Content Type to it I needed to find the Lookup list values for one of the import fields.  In looking for a list of lookup values I started with this code:

        public static SPList GetListByName(SPWeb web, string listName)

        {

            SPList retVal = null;

            foreach (SPList list in web.Lists)

            {

                if (list.Title.ToLower().Equals(listName.ToLower()))

                {

                    retVal = list;

                }

            }

            return retVal;

        }

That is, I passed in the current web and the list name that I was looking for and iterated the lists in the web looking for a name match.  That code quickly became this code:

        public static SPList GetListByName(SPWeb web, string listName)

        {

            return web.Lists[listName.ToLower()];

        }

In this code I let the object's enumerator handle the iteration for me.  So quick and easy and I'm done - but not so fast.  The only problem was that it didn't work.  The first time I looked for a Lookup Column that wasn't in the current web an Exception was thrown. Almost as soon as I started importing I needed a Lookup Column that was a site column and the document was being uploaded into the Documents folder in a sub-site, in this particular case, two sites down from the root.

Once I realized that the List existed but in a different context than that in which I was looking, I figured all I would need to do was get to the root and start looking using recursion, but instead of starting at the top and searching down, I thought that starting from where I was and moving up was a better approach.  In the instance where the List is in the parent web it is easier and faster to move up using web.ParentWeb from where you are, rather than iterating down through all of the child webs using web.Webs from the root.  That got me to this point:

        public static SPList GetListByName(SPWeb web, string listName)

        {

            SPList retVal = web.Lists[listName.ToLower()];

           

            if (retVal == null) // recurse up

            {

                if (web.ParentWeb != null)

                {

                    retVal = GetListByName(web.ParentWeb, listName);

                }

            }

            return retVal;

        }

But as you can see I forgot about the Exception being thrown, so I put the recursive call into a catch block and ended up with this code:

        public static SPList GetListByName(SPWeb web, string listName)

        {

            try

            {

                SPList retVal = web.Lists[listName.ToLower()];

            }

            catch

            {

                if (retVal == null) // recurse up

                {

                    if (web.ParentWeb != null)

                    {

                        retVal = GetListByName(web.ParentWeb, listName);

                    }

                }

            }

            return retVal;

        }

This approach was the one that finally worked.  If it didn't find the list by name in the current lists for the web it would throw an Exception and the catch block would then check to make sure that the retVal was still null, on the chance that the exception was thrown after it was set.  If it was null, it looked to see if the current web had a parent web and if so used that web to recursively call the method.  The two base cases in this recursion are:

  • 1. The code in the try block does not throw an error, in which case the list was found, or
  • 2. The web.ParentWeb is null, which means we are at the root of the site and the list does not exist.

That wraps it up for this time, hope it made your life a little easier.

Posted: May 18 2008, 11:04 PM by JohnF | with 1 comment(s)
Filed under: , ,
MOSS Enterprise Search. Part 2

In this part of the series you will learn how to set up Search Scopes. Search scopes allow to create specially defined groupings of searchable content, which can be chosen by users when executing a search.

  1. Go to the Sharepoint 3.0 Central Administration site
  2. Click on the Search Settings link in the Search section:
    image
  3. Click View Scopes in the Scopes section:
    image 
  4. Click New Scope link in the toolbar:
    image 
  5. In the Create Scope wizard you can specify title, description and target search page for the new scope. image
  6. After pressing Ok button you get back to the View Scopes page and now you see your scope in the list:image
  7. Now click on "Add rules" link to start a New Scope Rule wizard. Four types of scope rules are supported: Web Address, Property Query, Content Source and All Content. In our example we want the scope to include MOSS site users, so we choose Property Query scope rule type, and as a property restriction we use contentclass, specifying following query: urn:content-class:SPSPeople image
  8. Then we choose how the rule will be applied to the overall scope: whether any item that matches the rule will be included in the scope, or excluded from the scope, or any result in the scope has to match this rule. In our example we choose "Include". Then click "OK" to apply the rule.
  9. Now, if you want this search scope to be available before the next scheduled update, you can force update by going back to Search Settings page in Shared Services site (use site breadcrumb image ) and clicking "Start update now" link: image
  10. New search copes are not added to the existing site collections automatically. We need to perform the following steps to make the scope show in the search drop down:
    • On the portal home page select Site Actions -> Site Settings -> Modify All Site Settings
    • Click Search Scopes in the Site Collection Administration section
    • Click Search Dropdown link
    • In the scopes section choose the scopes you want to show up the search drop down, then press Ok to apply changes.
    • Now wait until the scheduled update completes and you should see your new search scope among those in the search drop down list.