Using BaseXsltListWebPart and XslListViewWebPart

Working with the . BaseXsltListWebPart sucks, especially when you are trying to use it as a concrete class, extending / changing the way it functions. Everything is sealed or internal, etc. etc. Shock me, shock me with SharePoint. Even if you instantiate an XslListViewWebPart within another WebPart derived class, there are a lot of features that are not available. Most notably, you will lose a bunch of menus.
The best way of doing it is to have a pre-existing BaseXsltListWebPart that already exists. Then you can just loop through the WebParts by using the WebPartManager.WebParts collection, and get a particular WebPart type by using Enumerable.OfType to filter the elements of an IEnumerable based on a specified type, in this case XsltListViewWebPart. Following, we are going to use the XsltListViewWebPart.XmlDefinition property so we can instantiate a new XmlDocument object. After you can execute any changes, then reset the property of the WebPart.

[csharp]

var view = manager.WebParts.OfType().FirstOrDefault();
var xmlDoc = new XmlDocument();
if (view != null) xmlDoc.LoadXml(view.XmlDefinition);
if (xmlDoc.DocumentElement != null)
{
// Do Stuff
}
string xmlDefinition = xmlDoc.OuterXml;
if (view != null) view.XmlDefinition = xmlDefinition;

[/csharp]

Share

Setting Continuous Integration For WebParts For Hourly Builds

There will be occasions when building custom WebParts under a Continuous Integration strategy where you don’t necessarily want to just build on check-in, but also want to run continuous builds on a time laced schedule, regardless of whether it has been check-in or not. When attempting to just use triggers, you may find that this doesn’t work exactly.

Firstly, under most orthodox considerations a build is not considered to be under a CI umbrella if it is not triggered by a check-in. However, to get around this issue you can use Check-ins do not trigger a new build as a trigger then use the inbuilt Window scheduler to call TFSBuild.exe while passing in the correct arguments with the /msBuildArguments switch. Batch it up, and you will be ready to rock and roll!

Share

Free SharePoint Redirection WebPart Programming SharePoint WebParts With LINQ to Active Directory Part 2

In the first part of this series, I illustrated the initial building of the primary WebPart class and the workhorse method that taps into Active Directory using LINQ to Active Directory to retrieve the current user’s department. Now, we have to use the returned department string to query down into a helper redirection SharePoint list and use a LINQ query to compare the two strings. We can grab the corresponding value out of the URL column, and they using standard redirection techniques push the user to the destination.

The PushUserToDivisionSite method is responsible for the actual redirection of the user. Firstly, a new SPSite & SPWeb object will be instantiated using the Url property, then a SPList constructed using the List property. To build the Where construct a SPList.Items.Cast<SPListItem>().Where is used performing an Equals on the department of the user and the value of the Title column. This should actually be a String.Compare so that you could bypass any case sensitivity problems, but I am just noticing that now. So you might want to fix that. An Enumerable.FirstOrDefault is used to return the desired SPListItem, and the URL value brought out. This value is then used in a trivial Page.Response.Redirect.

[csharp]

private void PushUserToDivisionSite()
{
using (var site = new SPSite(Url))
{
using (SPWeb web = site.OpenWeb())
{
SPList list = web.Lists[List];
var results = list.Items.Cast().Where(item => Equals(item[“Title”].ToString(), GetCurrentUserDepartment()));
if (results.Count() > 0)
{
SPListItem hydratedItem = results.FirstOrDefault();
string url = hydratedItem[UrlProperty].ToString();
if (!string.IsNullOrEmpty(url))
{
Page.Response.Redirect(url, true);
}
else
{
HandleException(new Exception(“Redirection Did Not Occur. Please Check The URL Property Of The List Being Used.”));
}
}
}
}
}

[/csharp]

The CreateChildControls method of the WebPart doesn’t do much besides call relevant helper methods. Since the GetCurrentUserDepartment method will either return the department or a constant string value as specified in the global fields, that can simplify be leveraged in a switch. So, either the department is returned, or the constant matches and a new Exception is thrown using the HandleException method which doesn’t do much but emit a literal control.

[csharp]

protected override void CreateChildControls()
{
if (!_error)
{

try
{
base.CreateChildControls();
string department = GetCurrentUserDepartment();
switch (department)
{
case _breakStatement:
HandleException(new Exception(“It Appears Your Active Directory Account Has No Department Set!”));
break;
default:
PushUserToDivisionSite();
break;
}
}
catch (Exception ex)
{
HandleException(ex);
}
}
}

[/csharp]

And that’s it. So going through this again, I think there are two big things that LINQ to Active Directory provides that are crucial to recognize, regardless of whether you like the actual implementation of the concept.

  1. Providing a layer of abstraction over Active Directory functions promotes standardization and ease of use.
  2. Being able to use LINQ querying constructs is extremely helpful when trying to keep code succinct and providing homogenous querying mechanisms.
Share