Tuesday, August 16, 2011

Cross-Site (Web) XsltListViewWebPart

It's been awhile since I've updated the blog, but just stumbled on something that may help anyone looking to display list information across multiple sites within a single site collection. Previously we handled this through jQuery, but I've found a much better way to display this information without the use of a CQWP, and the solution was lying directly under my nose the whole time.

I was looking at creating a list view web part that would allow us to present data from one Web on another Web while maintaining the same look and functionality of the ListViewWebPart. I created a web part project in Visual Studio, and began hacking apart the XsltListViewWebPart class in Reflector (shh... don't tell), when I noticed a property in the XsltListViewToolPart class called "WebId". Why would WebId be a property in the XsltListViewWebPart you might ask? Very curious I thought...

To begin, I created a new view on the list that I wanted to share, and exported the .webpart file from the XsltListView. To export the .webpart file, you simple click on Site Actions > Edit Page, and on the List View Web Part context menu click "Export" to save the file to your local machine. Web Part files are simply an XML representation of the properties of the web part, and can be imported back into the Web Parts library at the parent site for reuse throughout your Site Collection.

  <webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
      <type name="Microsoft.SharePoint.WebPartPages.XsltListViewWebPart, Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
      <importErrorMessage>Cannot import this Web Part.</importErrorMessage>
        <property name="InitialAsyncDataFetch" type="bool">False</property>
        <property name="ChromeType" type="chrometype">Default</property>
        <property name="Title" type="string" />
        <property name="Height" type="string" />
        <property name="CacheXslStorage" type="bool">True</property>
        <property name="ListDisplayName" type="string" null="true" />
        <property name="AllowZoneChange" type="bool">True</property>
        <property name="AllowEdit" type="bool">True</property>
        <property name="XmlDefinitionLink" type="string" />
        <property name="DataFields" type="string" />
        <property name="Hidden" type="bool">False</property>
        <property name="ListName" type="string">{B7B83EDB-714E-47A8-AF42-92A194B09169}</property>
        <property name="NoDefaultStyle" type="string" />
        <property name="AutoRefresh" type="bool">False</property>
        <property name="ViewFlag" type="string">8388613</property>
        <property name="Direction" type="direction">NotSet</property>
        <property name="AutoRefreshInterval" type="int">60</property>
        <property name="AllowConnect" type="bool">True</property>
        <property name="Description" type="string" />
        <property name="AllowClose" type="bool">True</property>
        <property name="ShowWithSampleData" type="bool">False</property>
        <property name="ParameterBindings" type="string">
			&lt;ParameterBinding Name="dvt_sortdir" Location="Postback;Connection"/&gt;
			&lt;ParameterBinding Name="dvt_sortfield" Location="Postback;Connection"/&gt;
			&lt;ParameterBinding Name="dvt_startposition" Location="Postback" DefaultValue=""/&gt;
			&lt;ParameterBinding Name="dvt_firstrow" Location="Postback;Connection"/&gt;
			&lt;ParameterBinding Name="OpenMenuKeyAccessible" Location="Resource(wss,OpenMenuKeyAccessible)" /&gt;
			&lt;ParameterBinding Name="open_menu" Location="Resource(wss,open_menu)" /&gt;
			&lt;ParameterBinding Name="select_deselect_all" Location="Resource(wss,select_deselect_all)" /&gt;
			&lt;ParameterBinding Name="idPresEnabled" Location="Resource(wss,idPresEnabled)" /&gt;
			&lt;ParameterBinding Name="NoAnnouncements" Location="Resource(wss,noXinviewofY_LIST)" /&gt;
			&lt;ParameterBinding Name="NoAnnouncementsHowTo" Location="Resource(wss,noXinviewofY_DEFAULT)" /&gt;
        <property name="Xsl" type="string" null="true" />
        <property name="CacheXslTimeOut" type="int">86400</property>
        <property name="WebId" type="System.Guid, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089">820a89d6-8509-4bc4-9d39-4fd91e420f7a</property>
        <property name="ListUrl" type="string" null="true" />
        <property name="DataSourceID" type="string" />
        <property name="FireInitialRow" type="bool">True</property>
        <property name="ManualRefresh" type="bool">False</property>
        <property name="ViewFlags" type="Microsoft.SharePoint.SPViewFlags, Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c">Html, TabularView, Mobile</property>
        <property name="ChromeState" type="chromestate">Normal</property>
        <property name="AllowHide" type="bool">True</property>
        <property name="PageSize" type="int">-1</property>
        <property name="SampleData" type="string" null="true" />
        <property name="BaseXsltHashKey" type="string" null="true" />
        <property name="AsyncRefresh" type="bool">False</property>
        <property name="HelpMode" type="helpmode">Modeless</property>
        <property name="ListId" type="System.Guid, mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089">b7b83edb-714e-47a8-af42-92a194b09169</property>
        <property name="DataSourceMode" type="Microsoft.SharePoint.WebControls.SPDataSourceMode, Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c">List</property>
        <property name="AllowMinimize" type="bool">True</property>
        <property name="TitleUrl" type="string">/kb/Lists/Emerging Issues</property>
        <property name="CatalogIconImageUrl" type="string" />
        <property name="DataSourcesString" type="string" />
        <property name="GhostedXslLink" type="string">main.xsl</property>
        <property name="PageType" type="Microsoft.SharePoint.PAGETYPE, Microsoft.SharePoint, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c">PAGE_NORMALVIEW</property>
        <property name="DisplayName" type="string">OnlineWPItems</property>
        <property name="UseSQLDataSourcePaging" type="bool">True</property>
        <property name="Width" type="string" />
        <property name="ExportMode" type="exportmode">All</property>
        <property name="XslLink" type="string" null="true" />
        <property name="ViewContentTypeId" type="string">0x</property>
        <property name="HelpUrl" type="string" />
        <property name="XmlDefinition" type="string">&lt;View Name="{863AE444-CE71-4B03-A037-976A884DFA9B}" MobileView="TRUE" Type="HTML" DisplayName="OnlineWPItems" Url="/kb/Lists/Emerging Issues/OnlineWPItems.aspx" Level="1" BaseViewID="1" ContentTypeID="0x" ImageUrl="/_layouts/images/generic.png"&gt;&lt;Query&gt;&lt;OrderBy&gt;&lt;FieldRef Name="Modified" Ascending="FALSE"/&gt;&lt;/OrderBy&gt;&lt;Where&gt;&lt;And&gt;&lt;And&gt;&lt;Contains&gt;&lt;FieldRef Name="Intuit_x0020_Services"/&gt;&lt;Value Type="Text"&gt;Software (SaaS):Online Payroll&lt;/Value&gt;&lt;/Contains&gt;&lt;IsNotNull&gt;&lt;FieldRef Name="Issue_x0020_Status"/&gt;&lt;/IsNotNull&gt;&lt;/And&gt;&lt;Neq&gt;&lt;FieldRef Name="Issue_x0020_Status"/&gt;&lt;Value Type="Text"&gt;Updated&lt;/Value&gt;&lt;/Neq&gt;&lt;/And&gt;&lt;/Where&gt;&lt;GroupBy/&gt;&lt;/Query&gt;&lt;ViewFields&gt;&lt;FieldRef Name="Issue_x0020_Status"/&gt;&lt;FieldRef Name="LinkTitle"/&gt;&lt;/ViewFields&gt;&lt;RowLimit Paged="TRUE"&gt;5&lt;/RowLimit&gt;&lt;Aggregations Value="Off"/&gt;&lt;Toolbar Type="Standard"/&gt;&lt;/View&gt;</property>
        <property name="Default" type="string" />
        <property name="TitleIconImageUrl" type="string" />
        <property name="MissingAssembly" type="string">Cannot import this Web Part.</property>
        <property name="SelectParameters" type="string" />

The highlighted line shows the WebId property in the exported web part file. If you open the file in a text editor or Visual Studio, you can modify the WebId before uploading the new file to your Web Parts Gallery. By default, the WebId is Guid.Empty() or 00000000-0000-0000-0000-000000000000.

To get the WebId, fire up powershell on one of your sharepoint servers and use this snippet:

$web = Get-SPWeb http://[url]

Be sure to include the full path of the web, e.g. if the list is hosted under a subsite it would be http://sharepoint/listlocation.

Now that you have your WebId, copy it from the powershell window and paste it into the WebPart file property "WebId" overwriting the default value. Save the file.

Uploading the Web Part File
  1. Navigate to the top-level site in your site collection
  2. Click on Site Actions > Site Settings
  3. Click on "Web Parts" under the "Galleries" section
  4. Upload your .webpart file to the Web Part Gallery (Name the file something that will easily be recognizable when adding the web part to your pages. I also tend to organize my web parts into groups, and in this case I've created a new Group called "Cross-site List View Web Parts")
  5. Save your file properties.

At this point you should be at the "Web Part Gallery" items view. From here you can click on the title of your newly added web part to see how it will render on your pages.

To add the web part to a page in SharePoint, simply edit your page and click the "Add Web Part" option, find the group you created in the "Add Web Part" menu, and click on you web part to add it to the page. Don't forget to save or Checkin your page. If you have publishing enabled, be sure to publish the page so that the changes are available to all users.

Tuesday, April 12, 2011

Group Calendar - Default Display

So... as it always seems in my world, I get a lot of "That's great, but what about this?" questions. Getting the Group Calendar to display default resources was fine, but a new requirement to set the default display to month view popped up. Here's how you do it.

Within the code I provided in my previous post, if you kept the code line-for-line and included the jQuery reference, insert this line at the bottom:

MoveView('month', $(el).attr('ctxid'));

If you chose a less sophisticated approach, you could use:

MoveView('month', '[Context ID]');

This will automagically shift your Calendar view to the month view, still displaying your default resources.

Here is the complete code reference:

<script type="text/javascript" src="/Style Library/lib/jQuery.min.js"></script>

<script type="text/javascript">

var el = $(".ms-acal-rootdiv");

var xml = "\u003cEntities Append=\u0022True\u0022 Error=\u0022\u0022 DoEncodeErrorMessage=\u0022True\u0022 Separator=\u0022;\u0022 MaxHeight=\u00223\u0022\u003e\u003cEntity Key=\u0022All Computers\u0022 DisplayText=\u0022All Computers\u0022 IsResolved=\u0022True\u0022 Description=\u0022\u0022\u003e\u003cExtraData\u003e\u003cArrayOfDictionaryEntry xmlns:xsi=\u0022http:\u002f\u002fwww.w3.org\u002f2001\u002fXMLSchema-instance\u0022 xmlns:xsd=\u0022http:\u002f\u002fwww.w3.org\u002f2001\u002fXMLSchema\u0022\u003e\u003cDictionaryEntry\u003e\u003cKey xsi:type=\u0022xsd:string\u0022\u003eResourceMembers\u003c\u002fKey\u003e\u003cValue xsi:type=\u0022xsd:string\u0022\u003e1;#Computer 01;#2;#Computer 02;#3;#Computer 03;#4;#Computer 04;#5;#Computer 05;#6;#Computer 06;#7;#Computer 07;#8;#Computer 08;#9;#Computer 09;#10;#Computer 10;#11;#Computer 11;#12;#Computer 12;#13;#Computer 13;#14;#Computer 14;#15;#Computer 15\u003c\u002fValue\u003e\u003c\u002fDictionaryEntry\u003e\u003cDictionaryEntry\u003e\u003cKey xsi:type=\u0022xsd:string\u0022\u003eSPResourceId\u003c\u002fKey\u003e\u003cValue xsi:type=\u0022xsd:string\u0022\u003e30\u003c\u002fValue\u003e\u003c\u002fDictionaryEntry\u003e\u003cDictionaryEntry\u003e\u003cKey xsi:type=\u0022xsd:string\u0022\u003ePrincipalType\u003c\u002fKey\u003e\u003cValue xsi:type=\u0022xsd:string\u0022\u003eResourceGroup\u003c\u002fValue\u003e\u003c\u002fDictionaryEntry\u003e\u003c\u002fArrayOfDictionaryEntry\u003e\u003c\u002fExtraData\u003e\u003cMultipleMatches \u002f\u003e\u003c\u002fEntity\u003e\u003c\u002fEntities\u003e";

var sel = SP.UI.ApplicationPages.CalendarSelector.instance().getSelector(1, $(el).attr('ctxid'));

sel.selectEntities(xml, true);

MoveView('month', $(el).attr('ctxid'));


ExecuteOrDelayUntilScriptLoaded(_setDefaultResources, "sp.ribbon.js");

Tuesday, March 29, 2011

Displaying Default Resources on the Group Calendar

[IMPORTANT NOTE]  It has been pointed out that some of the forum users who have tried this solution cannot get it to work. I forgot to mention that I'm using JQuery-1.5.1.min.js, which is why you see $() references in the solution. You could use substitute the JQuery variable "ID" for the actual ID of the Web Part Zone, e.g. "WPQ1", but I would suggest uploading the JQuery min file to your Style Library and using the following reference:

<script src="/Style%20Library/JQuery-1.5.1.min.js" type="text/javascript">

Sorry for the miscommunication.

It's been awhile since I've posted any ground-breaking new discoveries, so I thought I would pass on a bit of info about the Group Calendar and displaying default groups. Disclaimer: this is still in beta, and not running on a production site yet.

I've stumbled across a few blog posts about the group calendar, and the need to display a default set of resources on the calendar. The OOB functionality requires the user to select a resource/resource group before items show up on the calendar. Being the stubborn developer that I am, I decided that I would come up with a fix for this based on a specific requirement from one of our Business Units. This solution works for Resource Groups, but I'm sure it can be modified to easily display resources or people, depending on your requirements.

Looking at the calendar in action, you will quickly realize that the calendar uses the picker dialog for selecting resources, and AJAX to render selected items on the calendar. So, how does one go about calling the necessary functions to populate the calendar? Magic! ;-)

I started by viewing the source of the parent page to get an idea of what was actually taking place when the picker dialog closes. Here is the event you are looking for:

Great! But how does this help you? You may notice that the dialog result is xml, and that setting the result requires a call to SP.UI.ApplicationPages.CalendarSelector.instance().getSelector(type, id). After a bit of searching in the SP.UI.Calendar.debug.js file, I found some information around the ResourceSelector and retrieving the selector type. If you do a search of the source code in your view source window for "add_resource", you'll see that the "Add Resources" link attribute "evtid" is "add_resource". Searching through the SP.UI.Calendar.debug.js on "add_resource" yielded this handy bit of information:

$p0.$z('add_resource', Function.createDelegate(this, function ($p1_0) {
            __spPickerDialogFunc(1, this.$w_1, true);

This shows that the type is 1, and add = true. Once I had that information, I just needed to track down the XML data being passed from the picker dialog. That's where Fiddler comes in. If you aren't familiar with Fiddler, you should be. I won't go into too much detail, but will give you the gist below.

First, I opened an instance of fiddler and launched IE, browsing to my home page (which contains my group calendar). I then clicked the "Add Resources" link, and added a Resource Group called "All Computers" and clicked "OK".

You'll see below that the events now display for each resource in the calendar.

I then went into fiddler, and took a look at the final request from Picker.aspx, and began scanning the TextView for any information that might be helpful.

And there it is, in an ecma encoded string. The full XML return value from the dialog window. I copied the ret variable and began scripting a new function for the home page.

NOTE:  If you don't already know this, you can build your javascript into an html or txt file and upload it to a document library for reference in a Content Editor Web Part. I've found that if you just paste the javascript directly into the Content Editor, SharePoint has a nasty habit of correcting it for you, which can really break your code. I typically put my text/html files into a folder called "ctrl" in the Style Library. That way, if I reuse the code on multiple pages, I can update one single file and call it a day.

Here is my final script to populate the calendar:

<script type="text/javascript" src="/Style Library/Jquery.min.js"></script>
<script type="text/javascript">

function _setDefaultResources() {
        var el = $(".ms-acal-rootdiv");
        var xml = "\u003cEntities Append=\u0022True\u0022 Error=\u0022\u0022 DoEncodeErrorMessage=\u0022True\u0022 Separator=\u0022;\u0022 MaxHeight=\u00223\u0022\u003e\u003cEntity Key=\u0022All Computers\u0022 DisplayText=\u0022All Computers\u0022 IsResolved=\u0022True\u0022 Description=\u0022\u0022\u003e\u003cExtraData\u003e\u003cArrayOfDictionaryEntry xmlns:xsi=\u0022http:\u002f\u002fwww.w3.org\u002f2001\u002fXMLSchema-instance\u0022 xmlns:xsd=\u0022http:\u002f\u002fwww.w3.org\u002f2001\u002fXMLSchema\u0022\u003e\u003cDictionaryEntry\u003e\u003cKey xsi:type=\u0022xsd:string\u0022\u003eResourceMembers\u003c\u002fKey\u003e\u003cValue xsi:type=\u0022xsd:string\u0022\u003e1;#Computer 01;#2;#Computer 02;#3;#Computer 03;#4;#Computer 04;#5;#Computer 05;#6;#Computer 06;#7;#Computer 07;#8;#Computer 08;#9;#Computer 09;#10;#Computer 10;#11;#Computer 11;#12;#Computer 12;#13;#Computer 13;#14;#Computer 14;#15;#Computer 15\u003c\u002fValue\u003e\u003c\u002fDictionaryEntry\u003e\u003cDictionaryEntry\u003e\u003cKey xsi:type=\u0022xsd:string\u0022\u003eSPResourceId\u003c\u002fKey\u003e\u003cValue xsi:type=\u0022xsd:string\u0022\u003e30\u003c\u002fValue\u003e\u003c\u002fDictionaryEntry\u003e\u003cDictionaryEntry\u003e\u003cKey xsi:type=\u0022xsd:string\u0022\u003ePrincipalType\u003c\u002fKey\u003e\u003cValue xsi:type=\u0022xsd:string\u0022\u003eResourceGroup\u003c\u002fValue\u003e\u003c\u002fDictionaryEntry\u003e\u003c\u002fArrayOfDictionaryEntry\u003e\u003c\u002fExtraData\u003e\u003cMultipleMatches \u002f\u003e\u003c\u002fEntity\u003e\u003c\u002fEntities\u003e";

        var sel = SP.UI.ApplicationPages.CalendarSelector.instance().getSelector(1, $(el).attr('ctxid'));
        sel.selectEntities(xml, true);
ExecuteOrDelayUntilScriptLoaded(_setDefaultResources, "sp.ribbon.js");

A few important items to note... if you have multiple calendars on a single page, you will need to find the id of the calendar you are populating. The ctxid is actually a dynamically populated id (via javascript) of the web part context, which in this case is WPQ2. Make sure that you are using the ExecuteOrDelayUntilScriptLoaded( function, "sp.ribbon.js") call. The context id of the web part is not assigned until sp.ribbon.js is fully loaded. Once you have all that, it will work like a charm.

As always, if you have any questions, feel free to ping me. Hopefully, this will save you some time and make you look like a rockstar!

Thursday, February 10, 2011

SharePoint 2010 Search - Thesaurus Files

This year is the year of search for us. We're looking at implementing fast, focusing on metadata and better tagging in our content, and improving the overall search experience for our users. With that in mind, I just wanted to touch on creating Thesaurus files in SharePoint 2010 Search, as I've found the content on Technet and MSDN to be a bit cryptic.

Modifying Thesaurus Files
If you've been referencing Technet (http://technet.microsoft.com/en-us/library/dd361734.aspx), there is some pretty good information on how to create thesaurus files to improve your search. There are two main priniples in a thesaurus file: expansion sets and replacement sets.

To create an expansion set, which essentially maps synonyms to a specific keyword, you simply need to add the following code to your thesasurus file:

    <sub>401 k</sub>

An important item to note, parentheses are not acceptable in a thesaurus file. I found this out the hard way when attempting to add <sub>401(k)</sub>, which is the approved standard for 401(k). Luckily for us, the parentheses are ignored in the keyword, so 401(k) will still appear in the search results, even when the user keys in 401-k.

To create a replacement set, the schema is similar:

    <sub>Internet Explorer</sub>

In this case, IE8 or IE7 would be replaced by Internet Explorer.

While we don't have much use for replacement sets, expansion sets have proven extremely valuable. Instead of providing Best Bets links via the Search Keywords administration tool, we can populate our search results with all synonyms immediately, which reduces the need for multiple clicks to get a specific result.

Updating Thesaurus Files

The update process is where I have found the least amount of information. Thesaurus files are stored in multiple locations on a SharePoint Server, and determining the correct location can be a real pain in the butt. We update our Thesaurus files in 2 locations in the /Program Files/Microsoft Office Servers/14.0/ folder.

First, we update the thesaurus files here: \Program Files\Microsoft Office Servers\14.0\Data\Config. Updates to the thesaurus files here will ensure that any new Search Service Applications that you create will have the updated thesaurus definitions when they spin up.

Second, we copy the thesaurus files to the: \Program Files\Microsoft Office Servers\14.0\Data\Applications\[GUID]\Config folder. The GUID will be the guid of your Search Service Application, which can be found using this bit of Powershell goodness: Get-SPServiceApplication. This powershell command will list all of your service applications and their corresponding IDs.

Once the files are copied to this location, you'll need to restart the search service for the changes to take affect. You can do this from Administrative Tools > Services > SharePoint Server Search 14, or by running these commands:

net stop osearch
net start osearch

Once the service is resarted, go to your search center and plug in one of the newly added expansion/replacement terms to see your results.

It is important to note that if you're running search on multiple servers, you will need to perform these steps on each server running search. If you already have multiple search applications running, you will also need to copy your thesaurus files to each config directory under the GUID folder for each search service application.

For safety sake, we also updated the tsneu.xml along with tsenu.xml. NEU is the language neutral thesaurus file, and ENU is the US English thesaurus file. Definitions for each language prefix can be found on technet.

Tuesday, February 8, 2011

Setting Managed Metadata Fields via Javascript - UPDATE

As I mentioned in a previous post, Managed Metadata fields can be set using Javascript. I've actually found an easier method to retrieve and update the values via javascript that I wish to share quickly.

Previously, I was retrieving the Managed Metadata Field Value in display format. I encountered an issue when attempting to use this value to update a form field on a modal popup however, due to multiple results in the Term Store being found for a single string. To remedy this, I found the hidden value for the Metadata Field including the GUID of the term. To do this, I used my handy Powershell script from my previous post, and located the field name for the Metadata Field. I then located the following XML for my field:

<Field Type="Note" DisplayName="Role_1" StaticName="RoleTaxHTField" Name="RoleTaxHTField" ID="{bbaf434e-cc7e-40b5-b43e-5605ee3c3543}" ShowInViewForms="FALSE" Required="FALSE" Hidden="TRUE" CanToggleHidden="TRUE" SourceID="{d96d858a-03f7-4b0f-a73f-fc0ee68996cd}" Customization="" ColName="ntext9" RowOrdinal="0"/>
    <Field Type="TaxonomyFieldTypeMulti" DisplayName="Role" List="{aff9fc9f-40b8-4a89-aaa3-f5f566117446}" WebId="d96d858a-03f7-4b0f-a73f-fc0ee68996cd" ShowField="Term1033" Mult="TRUE" Sortable="FALSE" Required="FALSE" Group="Knowledge Base Columns" ID="{5050205f-5771-40e1-b356-ec6c989147f1}" SourceID="{d96d858a-03f7-4b0f-a73f-fc0ee68996cd}" StaticName="Role" Name="Role" Version="4" EnforceUniqueValues="FALSE" Customization="" ColName="int8" RowOrdinal="0">
            <Value xmlns:q1="http://www.w3.org/2001/XMLSchema" p4:type="q1:string" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">d6d8e56a-06c9-4c99-a5b0-1ea8b6eb747fValue>
            <Value xmlns:q2="http://www.w3.org/2001/XMLSchema" p4:type="q2:string" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">50857e97-8bdf-4000-bf13-5b1ba34d745aValue>
            <Value xmlns:q3="http://www.w3.org/2001/XMLSchema" p4:type="q3:string" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">00000000-0000-0000-0000-000000000000Value>
            <Value xmlns:q4="http://www.w3.org/2001/XMLSchema" p4:type="q4:boolean" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">falseValue>
            <Value xmlns:q5="http://www.w3.org/2001/XMLSchema" p4:type="q5:boolean" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">falseValue>
            <Value xmlns:q6="http://www.w3.org/2001/XMLSchema" p4:type="q6:string" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">{bbaf434e-cc7e-40b5-b43e-5605ee3c3543}Value>
            <Value xmlns:q7="http://www.w3.org/2001/XMLSchema" p4:type="q7:boolean" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">falseValue>
            <Value xmlns:q8="http://www.w3.org/2001/XMLSchema" p4:type="q8:boolean" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">falseValue>
            <Value xmlns:q9="http://www.w3.org/2001/XMLSchema" p4:type="q9:boolean" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">falseValue>
            <Value xmlns:q10="http://www.w3.org/2001/XMLSchema" p4:type="q10:string" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">Microsoft.SharePoint.Taxonomy, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429cValue>
            <Value xmlns:q11="http://www.w3.org/2001/XMLSchema" p4:type="q11:string" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">Microsoft.SharePoint.Taxonomy.TaxonomyFieldValue>
            <Value xmlns:q12="http://www.w3.org/2001/XMLSchema" p4:type="q12:string" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">GetFilteringHtmlValue>
            <Value xmlns:q13="http://www.w3.org/2001/XMLSchema" p4:type="q13:string" xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">FilteringJavascriptValue>

As you can see, there are 2 fields listed in the XML. The first field is the hidden value including the GUID of the term or terms, and the second field is the container/display field that is rendered as a string in Display Mode.

On my display form for the items that will be receiving feedback, I added a hidden field in the XSLT, and set the value to 

<xsl-value-of select="@RoleTaxHTField" />

When opening the dialog, the arguments passed include the value of this field.  On my dialog I now set the following the hidden storage field of the Metadata Field to the value passed. Now when the user submits the feedback, the value is mapped to the correct term without any errors, and there is no need to run the javascript that forces the metadata field to update.

Monday, February 7, 2011

Working with Lists and Schemas

I thought I would put up a quick post about retrieving list schema definitions via powershell while at the SPTechCon 2011 in SF this week. I've been working on some new Metadata functionality with JQuery and the SPServices Library (http://spservices.codeplex.com/ courtesy of Marc D Anderson), and realized that it's a real pain in the a** working with Managed Metadata Columns in SharePoint.

Here's a quick reference for grabbing the XML Schema of a list definition so you can get to internal field names, column definitions, and the Taxomony Ids required for interacting with the TaxonomyClientService.

$site = Get-SPSite http://[Site Url]
$web = $site.OpenWeb() - note: leave the value blank for the top-level web, or specify "/web url" between the parentheses to retrieve a specific web
$list = $web.Lists["List Name"]
$list.SchemaXML | Out-File C:\Temp\schema.xml

Now you should have an xml file containing the schema of your list. Open the file in your XML editor of choice, and have a blast locating the attributes you need.

Tuesday, January 18, 2011

Publishing HtmlEditor on a Custom Application Page

As promised, I thought I would give you a quick tutorial on how to add an HtmlEditor to a custom application page in SharePoint 2010.

As a quick overview, we had a need for streamlining our content creation process. We use standard HTML blocks to perform custom XSLT transformation before posting the content to our customer facing website, and needed a structured method for storing and transforming the data. Initially, we used Reusable Content Blocks to store the base HTML, and then used some CSS to highlight the editable regions. Unfortunately, the process became very difficult to manage, and required us to train our content editors in html best practices, which was extremely inefficient.

To streamline the process, we created a custom HTML editor and gave the users simple menus to click which would allow them to enter just the content which we would then wrap with our predefined content blocks. The menu's allow a user to click a specific block type, key in the content, and click the save button to view the preview article before saving. Here are a few screen captures to illustrate:
Content Editor Menus

Content Editor Dialog

As you can see in the above images, we created a menu to allow for editing and adding of content blocks. When an option is clicked, a Dialog Window opens containing 1 or 2 rich html editors depending on the block type. We chose to go with the standard Publishing HtmlEditor control because our users liked the ribbon options for easily formatting text and inserting links. I have seen other similar implementations that use the Telerik RadEditor or another third-party editor for adding HTML content.

The Nuts and Bolts

The HtmlEditor can be found in the Microsoft.SharePoint.Publishing.WebControls namespace, and is intended to work specifically with publishing pages. The class is sealed, so creating a new editor from the base class is impossible. After a little bit of tweaking though, it really wasn't difficult to get the editor working on our custom application page.

I first created a new SharePoint Empty Project in VS 2010, and added a new Application Page to the /_layouts folder. I like to keep my custom pages organized, so I created a folder under Layouts called "Editor". To use the HtmlEditor, you will need to add references to the following DLL's in your project:

Microsoft.SharePoint.Publishing.dll - located in \14\ISAPI\
Microsoft.Web.CommanUI.dll - located in \14\ISAPI\

I then modified opened my ApplicationPage.aspx file and made the following modifications:

I removed the reference to the aspx.cs page, which is added by default, and changed the MasterPageFile to use v4.master instead of ~/masterurl/default.master. The reason for the different master page is that we have some heavy customization for our default branding, and I didn't want this to carry over to our application page.

I then added the following references:

These references ensure that you can add the HtmlEditor to the page, and that the Ribbon controls will load.

Next, in the PlaceHolderMain section I added a reference to the editor:

<Publishing:HtmlEditor ID="htmlEditor" runat="server" />

By default, the reference to the editor was not added to the designer.cs file, so you will need to manually add it if you want to interact with it in your aspx.cs file. 

In the aspx.cs file, you will need to add these two using statements:

using Microsoft.SharePoint.Publishing;
using Microsoft.SharePoint.Publishing.WebControls;

To fully configure the editor for use, you will need to override the OnInit() function. Here is the code I used:

        protected override void OnInit(EventArgs e)
            SPRibbon ribbon = SPRibbon.GetCurrent(this.Page);
            if (ribbon != null)

            htmlEditor.Field = new RichHtmlField();
            htmlEditor.Field.ControlMode = SPControlMode.Edit;
            htmlEditor.Field.EnableViewState = true;
            htmlEditor.Field.AllowReusableContent = false;
            htmlEditor.Field.MinimumEditHeight = "200px";


            btnSave.Click += new EventHandler(btnSave_Click);


As you can see, I also trim the Wiki controls from the Ribbon. I don't have a need for the Layout and Check out functions. I then create a new RichHtmlField() which stores the contents of the HtmlEditor. Notice that I set the field ControlMode to edit, and modify a few additional parameters to hide options from the ribbon. The final step is to add the RichHtmlField control to the page. Adding the field to the page causes the page to render the associated Ribbon Contextual Tabs. Without it, you would only see a text area for entering content, but the Ribbon would never display.

To get the rest of the editor wired up required some javascript to handle the population of the editor control, and a few hidden fields for storing parameters from the parent page such as editor type and control id. We have up to 8 editable sections for a standard article, so the id of the parent content area was necessary to maintain the position of our content blocks. I also perform an initial post back of the page via javascript in order to validate the variables and throw an error message is one of the required values is missing. 

To post the content back to the parent page, I use a button click event, and the following code to write the information back to the parent:

string close = "<script src="\"/_layouts/jquery/jquery-1.4.2.min.js\"" type="\"text/javascript\"">
<div id="\"content\"">
" + Html + "</div>
<script type="\"text/javascript\"">
var obj = new Object(); obj.content = $('#content').html(); obj.id = "
+ hdControlId.Value + "; window.frameElement.commonModalDialogClose(obj, 1);


This essentially clears the context of the page and returns a modalDialogClose() command with my returned values.


Hopefully this post will save you some time in trying to get the SharePoint HTML Editor to display on an application page. If you have any questions, feel free to drop me a line.

Friday, January 14, 2011

Javascript Auto-Populate Complex Fields

It's been awhile since my last post, but I've been hard at work rolling out new functionality to our portal. Recently, I've been creating several dialog actions in SharePoint 2010 to enable users to perform various functions. The new SharePoint dialog framework is a fantastic addition to the product, but you may hit a few road blocks when trying to perform tasks that should be fairly straight forward, like pre-populating a dialog with parameters from a parent window. Hopefully this post will help you stay sane.

One of the primary features of our portal is that it acts as a Knowledge Base for our Customer Care Agents. We are constantly striving to keep our content up-to-date, but with over 4000 knowledge base articles, it takes more than just 1 or 2 sets of eyes to keep that content updated. In an attempt to streamline the update process, we decided to add a feedback mechanism to allow users to submit suggestions or requests. The best method for storing and reporting on this information, in my opinion, was to create a custom list to store requests. Using a SharePoint list allows us to easily track requests, maintain an SLA for updating content, and generating notifications and tasks based on these items.

In v1 of the content feedback system left much to be desired. We only captured a simple url, and submitting feedback used an ajax and custom modal form to push the data to the list. Unfortunately, we were only capturing the url, which didn't offer us the ability to categorize and assign the feedback.

In v2 we wanted to use a more out-of-the-box approach, and auto-populate various fields to allow us to assign the request to a specific content owner or group based on Taxonomy fields and User Fields on the parent knowledge base article. Easy, right?

Unfortunately, many of the SharePoint JS library are undocumented. The Client OM offers some nice functionality, but in regards to modifying any of the advanced field types (Taxonomy Field, Rich Text Editor, User Field), there just isn't much out there. Yours truly decided that "no mountain is too high" and tackled pre-populating these field types anyway. After hours of sifting through thousands of lines of js, here are my findings. Hopefully they save you more time than it took me to discover them.

Taxonomy Field Values - how to set them via javascript

The Taxonomy Field proved to be the most difficult to auto-populate via javascript. The Taxonomy Field allows a user to paste values into the editable region of the field, but a web service call is required to validate the terms and populate the Taxonomy Field hidden storage with the correct Term Label and Guid.

I first needed to locate the script that loads the Taxonomy Field Control. The script can be found in the /14/TEMPLATE/LAYOUTS/ folder, and is called ScriptForWebTaggingUI.js. Step 1 complete, and the rest is butter, right? Unfortunately, ScriptForWebTaggingUI.js is minified, and there isn't a nice clean debug.js file to accompany it. Time to start digging. After a few painstaking hours, I stumbled across the appropriate method for updating the Taxonomy Field after populating the values.

Here are the steps I took

1. Created a hidden field on the parent display form using the following code:

<xsl:element name="input">
  <xsl:attribute name="type">hiddenxsl:attribute>
   <xsl:attribute name="id">hdArticleServicesxsl:attribute>
   <xsl:attribute name="value">
     <xsl:value-of select="@Services"/>

2. Next I the function to open the list form for my feedback list, and put a button on the form to call the function:

<script type="text/javascript">
        function OpenArticleFeedbackDialog() {
            var options = SP.UI.$create_DialogOptions();

            options.url = "/AboutC3/Lists/Article Feedback/NewForm_User.aspx";
            options.title = "Submit Article Feedback";
            options.width = 630;
            options.height = 500;
            options.args = {
                title: $('#hdArticleTitle').val(),
                category: $('#hdArticleSupportCategory').val(),
                services: $('#hdArticleServices').val(),
                attached: $('#hdArticleAttachedServices').val(),
                owner: $('#hdArticleOwner').val(),
                backup: $('#hdArticleOwnerBackup').val(),
                id: $('#hdArticleId').val(),
                url: location.href

        options.dialogReturnValueCallback = Function.createDelegate(null, CloseArticleFeedbackDialogCallback);

    function CloseArticleFeedbackDialogCallback(result, target) {
        if (result) {
            alert("Thank you for your feedback.");

As you can see, it's a standard showModalDialog call, but notice the options.args object. I'm using jQuery to grab the hidden field values and send them to the child window. 

3. Next, I created a function on the newform.aspx file to grab the variables and populate the fields on the form. I added this function to the "PlaceHolderAdditionalPageHead" place holder on the newform.aspx page.

<script type="text/javascript">
        function _setArticleValues() {
            var args = SP.UI.ModalDialog.get_childDialog().get_args();

            $.each(args, function (i, n) {
                switch (i) {

                    case "title":
                        $("input[title='Feedback Title']").val(n);

                    case "category":
                        var c = _parseTaxValue(n);

                    case "services":

                    case "attached":
                        _setTaxFieldValues('ctl00_ctl21_g_09d208ae_a4f5_4702_a96a_c661d67d2c11_ff151_ctl00_ctl02editableRegion'); break;

                    case "owner":

                    case "backup":

                    case "id":
                        $("input[title='Content Id']").val(n);

                    case "url":
                        $("input[title='Feedback URL']").val(_parseUrlValue(n));

        function _setTaxFieldValues(id) {
            var obj = new Microsoft.SharePoint.Taxonomy.ControlObject(document.getElementById(id).parentNode.parentNode.parentNode);

        function _parseUserValue(user) {
            var $h = $(user),
img = $h.find("img.ms-imnImg"),
output = "";

            if (img) {
                output = img.attr('sip');

            return output;

        function _parseTaxValue(input) {
            var s = input.split(";"),
output = "";

            if (s.length > 0) {
                for (var i = 0; i < s.length; i++) {
                    var t = s[i].split(":");
                    output += t[t.length - 1].replace('&', '&') + ";";

            return output;

        function _parseUrlValue(input) {
            var output = "",
s = input.split("&");
            if (s.length > 0) {
                output = s[0];

            return output;

        ExecuteOrDelayUntilScriptLoaded(_setArticleValues, "scriptforwebtaggingui.js")

As you can see, I'm performing quite a few functions to normalize the data which I will get into shortly. 

The primary script is called _setArticleValues, and I use the SharePoint ExecuteOrDelayUntilScriptLoaded function to wait for the taxonomy field js to load. ExecuteOrDelayUntilScriptLoaded is an extremely valuable function when attempting to update complex field values from javascript because in many cases the field controls don't exist until the initial script is complete.

4. I first added the fields to the form, and did a simple html source view to grab the dynamic id's of the controls. The next step was to grab the html of the taxonomy field by writing the js generated html to a div tag on the form. This is where I discovered that the editable region of the Taxonomy Field is just the ID of the parent div + "editableRegion". Setting the HTML of the editable region is easy enough using jQuery, but unlike the Rich Text Editor, the Taxonomy Field doesn't post it's editable region contents to a hidden storage field before submitting the form (I will go into the RTE functionality in depth next). This is where I got stuck and decided to torture myself by sifting through SharePoint JS, and how I discovered this function:


Unfortunately, this is part of the taxonomy control object, so you have to create an object before calling this function like so:

var obj = new Microsoft.SharePoint.Taxonomy.ControlObject(document.getElementById(id).parentNode.parentNode.parentNode);

This was the magic function to fix all of my pain. Once I ran this function, the taxonomy field values were automatically saved to the list item, and peace was restored to the galaxy. I can go into much more detail, but would rather get to the next field type.

Rich Text Editor - Setting Field Values

The above code doesn't really demonstrate how to pre-populate a rich text field, but another project of mine required a modal dialog html editor. Painful yes, but quite rewarding once it was complete. I will go into the details of creating an application page with the Microsoft.SharePoint.Publishing.WebControls.HtmlEditor in my next blog post, but for now I will show you how to auto-populate it with html.

1. Much like the Taxonomy Field, you need to find the ID of the control. In an application page, this can be done dynamically using the reference, but in a list form you will have to grab the id from the rendered source. 

2. Once you have the ID, it's really a piece of cake to set the field value using jQuery or Javascript. This is the code I used for my application page:


As you can see, the _hiddenDisplay field is the only field you need to set. Once this field is set, the contents are rendered accordingly. One item to note, when passing the argument to your child dialog, do not use the SP.Utilities.HttpUtility.htmlEncode function, as there is no decode function in the js.

User Field Values

The SharePoint user field is almost identical to the Rich Text Editor field, but requires a little bit of finessing to get the correct value. When an data form web part renders the xsl version of the User Field, quite a bit of html is injected to display the hyperlink and user presence image. That's where this function comes in:

function _parseUserValue(user) {
    var $h = $(user),
img = $h.find("img.ms-imnImg"),
output = "";
    if (img) {
        output = img.attr('sip');

    return output;}

As you can see, I simply convert the user field value to a jQuery object, and then run some simple html functions against it to grab the appropriate attribute that holds the email address of the user. I then set the User Field editable region with the email address value like so:


Fairly self-explanatory, but you still have to determine the ID of the rendered User Field, and the appropriate div where the editable region is located.


Auto-populating complex field types via javascript can be a real bitch. Determining what field types you are populating is the first step; you then need to determine what order the SharePoint scripts are loaded so you can execute your functions after the final script control has been loaded on the page. I hope this post helps save you some time, and keeps you sane. As always, feel free to drop me a note if this post helped, or if you have any additional questions. And please excuse the poor grammar and sentence structure; I spent most of last night working on this, and wanted to get it up here before I forgot my steps.