HttpCode

In a previous post I introduced the Automatic Portal Connection tool, which can be used to automatically setup the portal connection on new and existing sites.

I thought I would take a peek at how I've made this happen:

Firstly I'd like to introduce the SPPersistedObject:

The description MSDN uses is:

The Portal Connection tool has a class called PortalConfig which derives from SPPersistedObject this class holds the configuration information such as the portal name and portal URL:

/// <summary>
/// Simple persisted object that stores the portal connection name and the portal connection url
/// </summary>
public class PortalConfig : SPPersistedObject
{
    [Persisted]
    private string portalName = string.Empty;

    public string PortalName
    {
        get { return portalName; }
        set { portalName = value; }
    }

    [Persisted]
    private string portalUrl = string.Empty;

    public string PortalUrl
    {
        get { return portalUrl; }
        set { portalUrl = value; }
    }

    public PortalConfig()
    {

    }
    public PortalConfig(string name, SPPersistedObject parent, Guid guid)
        : base(name, parent, guid)
    {

    }
}

SPPersistedObject is a very handy class, especially for configuration type scenario that is used in this solution, a method that makes use of this object is:

/// <summary>
        /// Simple method to persist our settings to the site
        /// </summary>
        /// <param name="curWeb"></param>
        /// <param name="curSite"></param>
        public static void ApplyPortalConnectionSettings(SPWeb curWeb, SPSite curSite)
        {
            PortalConfig portalConfig = (PortalConfig)curSite.WebApplication.Farm.GetObject(
                                        new Guid(curSite.WebApplication.Properties[PROP_KEY].ToString())
                                        );

            if (curWeb.IsRootWeb)
            {
                curSite.PortalName = portalConfig.PortalName;
                curSite.PortalUrl = portalConfig.PortalUrl;
            }
            curWeb.Update();
        }

This object is filled out and persisted by the central admin page, then a feature staple gets this information when the site is created and applies it, but I'll expand on this in future posts.

The portal connection is pretty useful, say you have a web application for team sites and have self service site creation turned on you would probably like the portal connection to be set to your portal homepage. Just as a refresher the portal connection is the link at the top of your site:

I've put together a tool that will give you the ability to set the portal connection for new sites and also for newly created sites. Once the solution has been deployed and the features activated, from central admin you will see a new link:

Following this link you will be presented with the following page:

From here you can select the web application to work with and you can set the portal name and URL. By selecting the 'Apply To Existing Sites' checkbox, you will set portal connections to all the sites on that web application.

The SharePoint solution can be downloaded here, I'll be releasing the code soon, I want to release it to Codeplex, I just need to set it up first.

Here is a small screencast showing the tool in use

Edit: I've now setup the Codeplex project: http://codeplex.com/SPPortalConnection

If your experiencing long initial page load times and your servers are configured so they can't connect out to the internet, you can reduce this time by either allowing the servers access to crl.microsoft.com or by deselecting the 'Check for publisher's certificate revocation' option from within Internet Explorer. The Internet Explorer option can be found under the Tools menu, then Internet Options:

Another option is to add a host file entry so that crl.microsoft.com points to the localhost (127.0.0.1)

There is so much great content on MSDN, but often it's hidden away, so I like to blog about these finds so I have a chance to find them in the future.

Today's find is the Design Logical Architecture for Collaboration Sites.

In particular I like the advice surrounding team sites:

Some of my notes:

• Hosting the team sites in a dedicated web app - This gives you the power to apply web application policy (this goes for the last point as well), what we normally do is have a zone like admin.yourteamsiteurl, then we use policy so that our administrators have full access over the web application. This means they can go into any team site if needed.
• In large organisations keeping an eye on the growth of the team sites is important, you need to know how large the content database is and when to expand out to more databases. Make sure you setup site level warnings, so your administrators are on top of the situation.
• Ensure that the procedures for notifying users of inactive sites is occurring, you really want to be able to claim that space back.
• A nice path is helpful for your end users, we normally opt for team.yoursiteurl/sites/<teamsitename> (the default setting)

This article also feeds into another great find Logical Architecture Sample Design: Collaboration Sites

JQuery is my all time favorite JavaScript library, it's so simple to use and incredibly powerful, but if you include all the plugins that are available, I just don't think that you would find a better tool for client side scripting.

My favorite validation plugin is the 'Validation Plugin', let me give you an example of how it is used:

Lets say you have a signup form, you want the user to select a user name, a password with confirmation and an email address, assume all of this is inside a form tag named 'signup'.

All of the HTML input element ids are 'Password', 'ConfirmPassword', 'Email'.

The JavaScript would be:

<script type="text/javascript">
$().ready(function() {
$("#signup").validate({
        rules: {            
            UserName: {
                required: true,
                minLength: 2,
                remote: "/Account/CheckUserName"
            },
            Password: {
                required: true,
                minLength: 2
            },
            ConfirmPassword: {
                required: true,
                minLength: 5,
                equalTo: "#Password"
            },
            Email:{
                required: true,
                email: true,
                remote: "/Account/CheckEmail"
            }
        },
        messages: {
            
            UserName: {
                required: "Please enter a username",
                minLength: "Your username must consist of at least 2 characters",
                remote: jQuery.format("{0} is already in use")
            },
            Password: {
                required: "Please enter a password",
                minLength: "Your password must consist of at least 2 characters"
            },
            ConfirmPassword: {
                required: "Please provide a password",
                minLength: "Your password must be at least 2 characters long",
                equalTo: "Please enter the same password as above"
            },
            Email: {
                required: "Please enter your email address",
                minLength: "Please enter a valid email address",
                remote: jQuery.format("{0} is already in use")
            }
        }
    });
});
</script>

Now notice how I used the remote property with '/Account/CheckEmail' and '/Account/CheckUserName', these are URL's that will be called by the client side JavaScript, they will pass along the current value of the textbox, so you could write server side code to validate the input, an ASP.NET MVC Controller Method could look like:

public JsonResult CheckUserName(string username)
{
    return Json(CheckValidUsername(username));
}

Notice the use of a JsonResult, The ASP.NET MVC framework is great for this type of thing, combine both JQuery and the MVC framework and you have a powerful combination, Jeff Atwood has come to the same conclusion and used both of these tools to build stackoverflow.com. 

All of the above code is so clean and easy to read, can you ever remember saying that about JavaScript code?

Something a little less SharePoint. If you wanted to consume an RSS feed (such as my homepage) and your using .NET framework 3.5+, then you could use the following code:

XDocument rssFeed = XDocument.Load(@"http://httpcode.com/blogs/SyndicationService.asmx/GetRss");

var posts = from item in rssFeed.Descendants("item")
    select new
            {
                Title = item.Element("title").Value,
                Published = DateTime.Parse(item.Element("pubDate").Value),
                Url = item.Element("link").Value,

            };
//BlogPosts is a ListView
BlogPosts.DataSource = posts;
BlogPosts.DataBind();

How about taking my last 5 twitter posts, but lets remove my name:

XDocument twitterFeed = XDocument.Load(@"http://twitter.com/statuses/user_timeline/14554389.rss");

var titterPosts = from item in twitterFeed.Descendants("item")
            select new
            {
                Title = item.Element("title").Value.Replace("DanielPollard:","")                       

            };
//TwitterPosts is a ListView - Notice the Take(5) below
TwitterPosts.DataSource = titterPosts.Take(5);
TwitterPosts.DataBind();

There's a lot to love about Linq.

I was reading this MS KB article 'How to point to a custom 404 error page in Windows SharePoint Services 3.0 or in MOSS'. I thought I'd throw together a simple administrative page to pull it all together. I've packaged this up in this solution file.

Once you active the 'Manage Custom 404 Page' feature, you will get a new menu item in the Application Management page in Central Admin:

From here you get a simple page that you can type the 404 page name for the selected web application:

The code is super simple:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.SharePoint.WebControls;
using Microsoft.SharePoint.Portal.WebControls;
using Microsoft.SharePoint.Administration;
using System.Web.UI.WebControls;

namespace SP404Handler
{
    public class SP404HandlerPage : LayoutsPageBase
    {
        protected WebApplicationSelector lstWebApps;
        protected PageLevelError pageLevelError;
        protected Button ButtonDoneOK;
        protected TextBox txt404PageName;
        protected Microsoft.SharePoint.WebControls.InputFormSection I404Section;

        protected void lstWebApps_OnContextChange(object sender, EventArgs e)
        {
            try
            {
                SPWebApplication webApp = lstWebApps.CurrentItem;
                BindData(webApp);
            }
            catch (Exception err)
            {
                pageLevelError.ErrorText = err.Message;
            }

        }

        protected void DoneButtonOkClick(object sender, EventArgs e)
        {
            SPWebApplication webApp = lstWebApps.CurrentItem;
            try
            {
                webApp.FileNotFoundPage = txt404PageName.Text;
                webApp.Update();
            }
            catch (Exception ex)
            {
                pageLevelError.ErrorText = ex.Message;

            }
        }

        private void BindData(SPWebApplication webApp)
        {
            txt404PageName.Text = webApp.FileNotFoundPage;

        }
    }
}

The source can be downloaded from here, or a complied solution from here.

I read with interest the recent example solution architecture article posted on Technet. It goes through the logical architecture of a School MOSS implementation. They have some good recommendations on hosting hardware and have some interesting comments on the way they handle media hosting.

Of Course being good consultants they provide nice visio overlays of the logical architecture:

However I was surprised to see the following:

Basically they are saying that staff sites and student sites are hosted in the same web application. I hope staff aren't going to put sensitive information into their sites, because it would only take one human error assigning permissions to give students access to the site. However if the students and staff are in separate web applications you could use web application policy to block students, so even if they were accidentally given access by a human, they would be blocked.

I'm sure this has been thought about by these guys because further on in the article we find:

This is a classic example of where web application policy is so helpful and why it really pays to have a think about the implications of your design.