I was compiling an old solution package for SharePoint 2007, this solution has 6 web parts but the WSP package's manifest only has SafeControl lines for 4 of them.  Somehow, it is discriminating against my newest 2 additions to the family.

In VS.NET 2010, the settings for whether a web part feature should be included in SafeControl is off the WSP Package view.  It automatically adds the current DLL, as well as giving us an option to add more additional assemblies (via the special package solution designer).

In VS.NET 2008 and SharePoint 2007, the way it determines whether or not to include a Web Part when it generates the manifest file seems...  almost, bizarre and magical.

This is how it works

1. During packaging, VSeWSS reads the DLL to determine if there are web parts within it that needs a SafeControl line.
2. When it finds them, it modifies a temporary file that it uses during packaging, under project\bin\Debug\solution\manifest.xml
3. The packaging process than packs up everything under \solution\ into a WSP file, and the manifest file is stored within the WSP file.
4. What's confusing, is that VSeWSS is not reading the right DLL that's compiled from this project, instead, if you have an older copy of the DLL in the GAC, it will actually read the GAC version over your newly built DLL.
   
   The end result, is that you think you are crazy and you don't understand why it's arbitrarily deciding to add 4 SafeControl lines, but not all 6.

Fix

The fix is pretty simple, if you manually deploy the DLL to the GAC first, then repackage again, it'll pick up the additional web parts within the DLL and add them to your SafeControl list.

Why have I never seen this before

If you are deploying to the local machine for testing, you actually may not even see this error - since when you deploy the currently built solution to the local machine it also puts the new DLL into the GAC. 

This is a Single Page Application deployed to SharePoint, and talks to SharePoint via the Client Object Model as well as the REST interface.

The page does not Postback.  It always talk to SharePoint via AJAX.

So far:

• Package 1 ASPX page in a solution package
• Reference jQuery, Knockout
• Layout using Twitter's Bootstrap
• Grabs lists via Client Object Model
• Grabs list items via REST interface
• The darn thing is beautiful

To come next:

• CRUD for list items
• Document download
• Document upload?
• List paging
• Use different icons for lists and document libraries on left navigation
• A favicon
• An actual Title for the page
• Site navigation (this will do post back - since we'll be navigating between say http://server/ to http://server/publishing/ ).
• Quick search / filter
• An interesting picture thumb-nail viewer

Check it out on http://spaspa.codeplex.com/ and let me know what you think!

On a crazy Thursday afternoon I had the mad idea of building a Single Page Application on top of SharePoint.

This is a sneak preview of my work so far on this goal:

The story so far

• Everything in a SharePoint farm solution
  • Deploys to /_layouts/JL-SPA/SPA.aspx - one single page!
• UI layout using Twitter Bootstrap - what you see above is based on the Fluid example template
  • Twitter Bootstrap is based on Less.js
• UI binding using Knockout.JS
  • With Knockout.Mapping.js addon
• Additional glue with jQuery
• Reading from SharePoint via OOTB REST service API
  • The list of libraries from my current site is returned and bound to the list on the left (see above picture).  I call it a mini success in setting up the scaffolding.  Will continue another day.
• Exposes _spPageContextInfo object
• Expose SP.ClientContext objects/scripts

This is the entire project so far:

Still to come

• UI for lists
  • Sorting for lists.
  • Determine columns for lists.
• UI for viewing items
• UI for editing items
• ?  Add SPServices?  There are some pretty useful workflow use cases in this library.

Call for help!

I think I might be out of my mind on this one.  If you want to join in and hack some JavaScript, yell out and help me out! 

Great opportunity to learn some really cool technology and have a lot of fun!

Trimming field length in XSL

The itemstyle template may look something like this:

    <xsl:template name="FAQ" match="Row[@Style='FAQ']" mode="itemstyle">       
        <xsl:variable name="SafeLinkUrl">
            <xsl:call-template name="OuterTemplate.GetSafeLink">
                <xsl:with-param name="UrlColumnName" select="'LinkUrl'"/>
            </xsl:call-template>
        </xsl:variable>

        <dt>
            <a href="{$SafeLinkUrl}" class="title" onclick="GoToLink(this);return false;" target="_self">
                <xsl:value-of select="@Title" />
            </a>
        </dt>
        <dd>
            <xsl:choose>
                <xsl:when test="string-length(@Answer) &gt; 150">
                    <xsl:value-of select="concat(substring(@Answer,0,150),'...')" disable-output-escaping="yes"/>
                </xsl:when>
                <xsl:otherwise>
                    <xsl:value-of select="@Answer" disable-output-escaping="yes"/>
                </xsl:otherwise>
        </xsl:choose>
       </dd>
    </xsl:template>

The interesting part is where the @Answer field is rendered - if the length of this field is beyond 150 characters, it will return the first 150 characters and append an ellipsis (...)

Problem when we have a HTML field

The technique is pretty simple, but it is not fool proof - when the field you are trying to trim is an HTML / Rich field, you have a big problem - the trimming may suddenly cut off valid HTML, to return an invalid HTML.

Imagine, if the @Answer field was:

<div>
     <span>a great answer</span>
</div>

And we perform:

substring(@Answer, 25)

Then we'll get:

You are now returning really bad HTML to the browser:

<dd>
    <div>
        <span>a great answe...
</dd>

See how the HTML isn't terminated correctly with the proper end-tags.  If you are lucky, the browser guesses correctly and doesn't break your page.  Many times though, it's all down hill from here.

Using XSL to strip HTML tags from your field.

A very simple solution is to add an additional XSL template to strip out the HTML tags from your field before rendering it.  A simple version can be found on this article.

1.  Add this removeHtmlTags template in your XSL

<xsl:template name="removeHtmlTags">
    <xsl:param name="html"/>
    <xsl:choose>
      <xsl:when test="contains($html, '&lt;')">
        <xsl:value-of select="substring-before($html, '&lt;')"/>
        <!-- Recurse through HTML -->
        <xsl:call-template name="removeHtmlTags">
          <xsl:with-param name="html" select="substring-after($html, '&gt;')"/>
        </xsl:call-template>
      </xsl:when>
      <xsl:otherwise>
        <xsl:value-of select="$html"/>
      </xsl:otherwise>
    </xsl:choose>
  </xsl:template>

2. Modify your ItemStyle to use the removeHtmlTags template in an XSL variable

    <xsl:template name="FAQ" match="Row[@Style='FAQ']" mode="itemstyle">       
        <xsl:variable name="SafeLinkUrl">
            <xsl:call-template name="OuterTemplate.GetSafeLink">
                <xsl:with-param name="UrlColumnName" select="'LinkUrl'"/>
            </xsl:call-template>
        </xsl:variable>
        <xsl:variable name="textAnswer">
            <xsl:call-template name="removeHtmlTags">
                <xsl:with-param name="html" select="@Answer" />
            </xsl:call-template>
        </xsl:variable>
        <dt>
            <a href="{$SafeLinkUrl}" class="title" onclick="GoToLink(this);return false;" target="_self">
                <xsl:value-of select="@Title" />
            </a>
        </dt>

        <dd>
            <xsl:choose>
                <xsl:when test="string-length($textAnswer) &gt; 150">
                    <xsl:value-of select="concat(substring($textAnswer,0,150),'...')" disable-output-escaping="yes"/>
                </xsl:when>
                <xsl:otherwise>
                    <xsl:value-of select="$textAnswer" disable-output-escaping="yes"/>
                </xsl:otherwise>
            </xsl:choose>
       </dd>
    </xsl:template>

Summary

1. Use substring to strip fields to a certain number of characters - so you don't return everything
2. For HTML fields, add removeHtmlTags template and use call-template to get the result into an XSL variable first

Story

• I have a feature receiver stapled to my site template, it checks a few conditions, does a few things, then creates 1 subsite and stops
• The new subsite is created, and runs the same receiver, it checks a few more conditions, does a few things.  It shouldn't create any subsites.
• This afternoon, it did.  The process did not stop.
• Ouch

Problem

• You can't delete the higher level web object when it has subsites.  You can't follow the subsites because the path has gone way deep.
• Sounds like time for a good PowerShell script

Script

$web = get-spweb http://dev/ourprojects/nsw/1000

function CleanSite( $w )
{
    $ws = $w.Webs;
    foreach( $w1 in $ws)
    {
        CleanSite($w1)
    }
    echo $w.Title
    $w.Delete()

}

CleanSite $web

Closing thoughts

My initial fears were that the feature receivers has gone berserk and I'd have hundreds of subsites to clean up.  This turned out to be not the case - I only had about 12 subsites.  I'm wondering if there was a SharePoint error that prevented deeper subsites from being created.  So the disaster really wasn't that bad.  12 subsites I can manage.