Sending Emails using User/Sandboxed Solutions

If you've done any kind of work ​emailing using SharePoint you are probably aware of the SendEmail method available through the SharePoint object model as part of the Microsoft.SharePoint.Utilities namespace. It's very useful as it allows us to send emails with a minimum amount of effort and without having to know the SMTP settings and such like.

In user/sandboxed solutions, this method is not available so we're left in a bit of a limbo, not knowing how to achieve it as there's nothing else available in the object model that achieves the same thing. Let's say we have a custom "Contact Us" webpart which sends someone an email with the contact information: how can you achieve the same thing?

We could use the System.Net.Mail methods available to us, but is it reasonable to expect a content author to supply the webpart with the appropriate SMTP settings? Why is that an issue? Well, these settings can be accessed programmatically using the object model which would resolve this minor difficulty, but they are not available in a sandbox. They exist at Web Application level and are therefore off limits.

Fortunately, there is another way, and that is through using SharePoint Designer workflow. You can trigger a workflow to run programmatically and also supply information to the workflow and set the initiation values. Here's the code to start a workflow:

/// <summary>
/// Method to handle starting the appropriate Workflow as specified by the Site Collection Workflow Name property
/// </summary>
private void StartWorkflow()
{
SPWorkflowAssociation wfa = SPContext.Current.Web.WorkflowAssociations.GetAssociationByName(this.SiteCollectionWorkflowName, CultureInfo.InvariantCulture);
wfa.AssociationData = this.GetWorkflowInitiationData();
SPContext.Current.Site.WorkflowManager.StartWorkflow(null, wfa, this.GetWorkflowInitiationData(), SPWorkflowRunOptions.Asynchronous);
}

/// <summary>
/// Method to construct the Workflow Initiation/Association Data
/// </summary>
/// <returns>A string containing the XML schema and values necessary for the Association Data</returns>
private String GetWorkflowInitiationData()
{
String schema = "<dfs:myFields xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" " +
"xmlns:dms=\"http://schemas.microsoft.com/office/2009/documentManagement/types\" " +
"xmlns:dfs=\"http://schemas.microsoft.com/office/infopath/2003/dataFormSolution\" " +
"xmlns:q=\"http://schemas.microsoft.com/office/infopath/2009/WSSList/queryFields\" " +
"xmlns:d=\"http://schemas.microsoft.com/office/infopath/2009/WSSList/dataFields\" " +
"xmlns:ma=\"http://schemas.microsoft.com/office/2009/metadata/properties/metaAttributes\" " +
"xmlns:pc=\"http://schemas.microsoft.com/office/infopath/2007/PartnerControls\" " +
"xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">" +
"<dfs:queryFields /><dfs:dataFields><d:SharePointListItem_RW>{0}</d:SharePointListItem_RW>" +
"</dfs:dataFields></dfs:myFields>";


StringBuilder sb = new StringBuilder();
sb.AppendFormat("<d:EmailTo>{0}</d:EmailTo>", this.SendToEmailAddress);
sb.AppendFormat("<d:EmailSubject>{0}</d:EmailSubject>", this._subject.Text);
sb.AppendFormat("<d:EmailText>{0}</d:EmailText>", this._comments.Text);
sb.AppendFormat("<d:AutoResponseTo>{0}</d:AutoResponseTo>", this._email.Text);
sb.AppendFormat("<d:AutoResponseSubject>{0}</d:AutoResponseSubject>", this.AutoResponseSubject);
sb.AppendFormat("<d:AutoResponseText>{0}</d:AutoResponseText>", this.AutoResponseText);
return String.Format(schema, sb.ToString());
}

The StartWorkflow method is where the workflow starts and the GetWorkflowInitiationData is where the XML erquired to set the initiation properties are set up. From what I've seen, the XML stays pretty-much the same with properties being set using the "dataFields" namespace "d:". The property names are workflow initiation properties I set up in my workflow.  The SiteCollectionWorkflowName used in the StartWorkflow method is a property of the webpart which could be hidden away.

Google Maps vs Bing Maps

One of the nice things about Google Maps is the ability to embed a static image of your map, rather than having to use a JavaScript API or resorting to downloading multiple JavaScript files to support the map's features. Simply using a URL to point to one of Google's services was enough when it was used as the SRC attribute of an IMG tag - simple. It was something that was missing, until fairly recently, from Bing Maps.

Fortunately, Bing Maps have caught up and now have a REST API available to support static imagery in the same way as Google Maps. The details can be found here: http://msdn.microsoft.com/en-us/library/ff701724.aspx.

Simply adding the correct URL to the SRC attribute of an IMG tag creates the correct image to embed thereby avoiding multiple JavaScript downloads and any use of a client-side API.

Publishing Images and Search Indexing

This may be something that you already know, but in SharePoint 2007 fields based on the Publishing Image​ field type caused problems when you wanted to use these kinds of field in the Search Results. 
The problem became apparent if you wanted to use something like a Roll Up Image on content pages where you wanted to display the image both using Content Query Web Parts (which don't have a problem with Publishing Image fields) and in Search Results. The problem is, Search doesn't index fields of this type. It just doesn't. So you can set up your metadata property which you can add a property mapping for the Publishing Rollup Image field but when you try to surface the data contained by the property in search it contains nothing.

Having experienced this problem in 2007 during a custom Search project, I was already aware of the limitation and then SharePoint 2010 came around and a similar requirement came about. I was approached to take a look into whether it was still a problem and had some expectation that perhaps it had been resolved. Alas, it has not.

So, buyer beware!!

How To Resolve

Fortunately, there is a simple work-around. Create a text field into which you automatically add the contents from your Publishing Image field as text by whatever means you prefer and then use that to set up your metadata property instead. Works like a charm.

Removing Unnecessary CSS

I've been recently looking at​ performance of public-facing websites built with SharePoint 2010 and, following on from Chris O'Brien's blog on removing unnecessary JavaScript files for anonymous users that are loaded as part of the Script-on-Demand framework, I was browsing through the kinds of files requested and whether they were important or not.

One thing I noticed was that there are several CSS files also loaded by SharePoint that are not always necessary for anonymous users. Things like controls.css or forms.css and maybe even corev4.css in some cases may not be needed. Therefore, I decided to approach the problem with the same mindset already adopted for the additional JavaScripts which made some sense to be able to have a control which would be able to strip out unnecessary or superfluous JavaScript and CSS files. In addition to Chris O'Brien's code example, here's mine:

private List _cssFiles = new List();
private List _cssFileIndicesToBeRemoved = new List();
private List _foundCssFiles = new List();

public string CSSFiles { get; set; }

protected override void OnInit(EventArgs e)
{
    base.OnInit(e);

    // store the css files property into the class private List variables
    if (String.IsNullOrEmpty(this.CSSFiles) == false)
    {
        string[] css = this.CSSFiles.Split(new char[] { ';' });
        this._cssFiles.AddRange(css);
    }
}

protected override void OnPreRender(EventArgs e)
{
    base.OnPreRender(e);

    // remove files but only for anonymous users
    if (HttpContext.Current.User.Identity.IsAuthenticated == false)            
    {
        // this.RemoveScripts();
        this.RemoveCSS();
    }
}

private void RemoveCSS()
{
    int index = 0;
    for (int iteration = 0; iteration < 2; iteration++)
    {
        IList files = null;
        FieldInfo prop = null;
        this._cssFileIndicesToBeRemoved = new List();

        if (iteration == 0)
            prop = this.GetFieldInfo(SPContext.Current, "m_css");
        else
            prop = this.GetFieldInfo(SPContext.Current, "m_orderedCss");
                
        if (prop != null)
        {
            files = (IList)prop.GetValue(SPContext.Current);
            foreach (var file in files)
            {
                FieldInfo cssRegisterProp = this.GetFieldInfo(file, "CssReference");
                if (cssRegisterProp != null)
                {
                    string cssFileName = cssRegisterProp.GetValue(file).ToString();

                    // add the file to the list of indices for removal
                    if (string.IsNullOrEmpty(this._cssFiles.Find(delegate(string sFound)
                    {
                        return cssFileName.ToLower().Contains(sFound.ToLower());
                    })) == false)
                    {
                        this._cssFileIndicesToBeRemoved.Add(index);
                    }
                    else
                    {
#if DEBUG
                        this._foundCssFiles.Add(cssFileName);
#endif
                    }
                }
                index++;
            }
                    
            // reset the index counter and remove the required files
            index = 0;
            foreach (int j in this._cssFileIndicesToBeRemoved)
            {
                files.RemoveAt(j - index);
                index++;
            }
            prop.SetValue(SPContext.Current, files);                    
        }
    }
}

private FieldInfo GetFieldInfo(object Type, string FieldName)
{
    Type t = Type.GetType();
    FieldInfo prop = t.GetField(FieldName, BindingFlags.Instance | BindingFlags.NonPublic | BindingFlags.Public);
    return prop;
}

To explain a little. The CSS files are "registered" using the CSSRegistration control. When a CSS file is registered it gets stored in a CSSReferences property of the current SPContext which is an internal property of type ICollection<CssRegistrationRecord>. This property is read-only which means that while we can look at the collection we cannot write any changes back through this property. Fortunately, by looking at the Get for this property, we can see that it uses two private variables - m_css and m_orderedCss - to work out the ICollection contents. By accessing these two variables directly and changing them using reflection we can trim out the unnecessary files in the same way that we can trim out unwanted JavaScript files for anonymous users.

In the example above I haven't included Chris's code or class-level variables to make it slightly easier to read. Suffice to say that I've added his code into a separate method which is called from the OnPreRender event (see the commented out this.RemoveScripts(); line). I've also changed the OnInit slightly to check for empty strings prior to attempting to extract the entered value into the internal List variable.

UI Design and Taxonomy

Sometimes, when you're designing a UI for a better experience for Users, you want to use some of the functionality usually reserved for content authors.

What do I mean? Well, normally in Publishing Sites, when you're in edit mode you expose components and UI to content authors and allow a great user experience. The page becomes published and then that same data might be shown to readers of the page as simple text or perhaps formatted in some HTML - either way, it's exposed as static data. But suppose you have a form which readers need to interact with to, say, select a set of search criteria which you have available. 

One such part of SharePoint 2010 which is likely to be used frequently is Managed Metadata and taxonomy. It may be you want to allow Users to select a Term from your Term Set in search rather than allowing a manual text input field. Fortunately, this is something someone has thought about at Microsoft and therefore created the Taxonomy Web Tagging Control.

First of all, a little about why a separate control is necessary.

In Publishing, due to the way Page Layouts are closely tied in with Content Types Fields are exposed using the Field Controls which, obviously, use the underlying Field from the Content Type to store and retrieve it's data. Outside of a Page Layout the Field Controls in general fall down as they rely on this close relationship for their supply and storage and therefore cannot be used unless the underlying item has a Field within its Content Type that matches.

Taxonomy Field Controls are no different, so therefore the Taxonomy Web Tagging Control steps in to allow coupling to the Term Store and Term Set directly, bypassing the need for a Content Type and freeing up the control to be used just about anywhere (see the hyperlink below for more information about this component).

Two slightly awkward bits of information are required: the Term Store ID (exposed as the SSPList property) and the Term Set ID (exposed as the TermSetList property). How do you get these?

Open up Central Admin and go to your Managed Metadata service - you'll see the Term Store ID exposed in the URL. If you navigate the Term Store to the Term Set you want to use and open up something like the IE Dev Toolbar you can step through the HTML structure to the LI tag of the Term Set and the ID attribute of the LI tag is your Term Set ID.

Here's some more information from Microsoft on the Web Tagging Control and how to use it: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.taxonomy.taxonomywebtaggingcontrol.aspx​

​

Google +1

If you like the "Like" function that sites like Facebook​ implement then you may be interested to know that Google will be launching its own version over the coming weeks in an attempt to make their search results more social.

From what I understand at present, you need to have a Google profile to be able to use the facility, but you'll be able to recommend sites that appear in search results - and at some point in the future offer the same functionality within your public-facing websites.

Read more about it here: http://googlewebmastercentral.blogspot.com/2011/03/introducing-1-button.html?utm_source=feedburner&utm_medium=email&utm_campaign=Feed%3A+blogspot%2FamDG+%28Official+Google+Webmaster+Central+Blog%29

SharePoint 2010 - Reducing Page Load Size

Having gone round-and-round in circles looking to disprove (and prove to myself) Chris O'Brien's blog article about removing unwanted and unnecessary JavaScript files from SharePoint 2010 when a public-facing website is accessed anonymously, I've basically satisfied myself that there doesn't appear to be any better way to do this.

As Chris explains, SharePoint 2010 includes a whole host of JavaScript files which can bloat a page quite considerably.  In a content author scenario, this isn't so much of a problem as the website will be accessed within an local and closed environment, more-often-than-not, and over the larger bandwidth that usually accompanies this it doesn't always pose a problem.  As soon as a website becomes public-facing, there are many more considerations which not only include bandwidth, but also client capabilities.

Any work that can be done to reduce page size is always worthy of consideration.  In light of this, referring to Chris here again, Microsoft introduced the Script On Demand framework in SharePoint 2010 to attempt to mitigate the page size.  Problem is the scripts still get downloaded, and quite a few, despite this. 

To solve it, Chris came up with a way to remove unnecessary JavaScript files from the list of registered files (which are stored in the HttpContext) but has had to use reflection to achieve this....it's not nice, but seems to be the only way to make it possible.

Here's his article explaining how - definitely worth consideration if performance is a concern.​

Continuing on from what Chris has said, another way to reduce the number of server requests is to use the ASP.NET ScriptManager which gets added to the masterpage and combine your own scripts into a single one. for instance you may be loading the base jQuery library as well as one or more plug-ins, plus your own custom JavaScript.  Here's how:

 

<asp:ScriptManager id="ScriptManager" runat="server" EnablePageMethods="false" EnablePartialRendering="true" EnableScriptGlobalization="false" EnableScriptLocalization="true">
    <CompositeScript>
      <Scripts>
        <asp:ScriptReference Path="<%$SPUrl:~sitecollection/Style Library/Scripts/scriptfile_001.js%>" ScriptMode="Release" />
        <asp:ScriptReference Path="<%$SPUrl:~sitecollection/Style Library/Scripts/scriptfile_002.js%>" ScriptMode="Release" />
        <asp:ScriptReference Path="<%$SPUrl:~sitecollection/Style Library/Scripts/scriptfile_003.js%>" ScriptMode="Release" />
      </Scripts>
    </CompositeScript>
</asp:ScriptManager>

 

Remember that doing this removes your files from the list of files used by the ScriptLink control.