If you’ve read my previous posts on FAST Search in SharePoint 2010, you’ll be familiar with my article where I describe the issues I had with the Content Distributor ports for FAST.
My initial research into this issue let me to the following blog: http://fastforum.info/viewtopic.php?f=6&t=223.
Basically the users commenting in this thread talk about an inconsistency between the Install_Info.txt file and the ContentDistributor.cfg file in terms of the port number which is set to 13390. It was always odd to me that the Install_Info.txt and ContentDistributor.cfg file were not consistent and many believe this to be incorrect.
The change that you would make would be an update to the FAST Search Connector in Central Admin, so that the port number reflects what’s in the ContentDistributor.cfg file. While this may work temporarily, this is INCORRECT!
The port for the Content Distributor should be AS IS reflected in the Install_Info.txt file. So 13391 if you stuck with the defaults.
Read the following from a KB article from MS:
The “Fast Connector SSA” may be incorrectly configured to use port 13390. The %FASTSEARCH%\install_info.txt” displays the Content Distributors with port “13391″, however the %FASTSEARCH%\etc\contentdistributor.cfg” displays port 13390. If the portfor the “Content Distributors” in the “Fast Connector SSA” was configured as “13390″, connectivity to FAST will fail. If this is the case, the “Content Distributors” in the “Fast Connector SSA” should be reconfigured to use port 13391 as stated in the install_info.txt.
Karine Bosch’s blog post on the SharePoint DateTimeControl is really great for understanding how to use this control in your custom web parts or application pages. It’s probably one of the only really good resources out there on this control.
So to summarize, the SelectedDate property let’s us know what date the user has selected. However, if the user didn’t enter a date the SelectedDate property returns Today’s date. Huh?
This presents a problem because of form submission. Let’s review a scenario where this causes issues:
- User enters a date in a DateTimeControl: April 3, 2011.
- User submits. Date is saved as April 3, 2011 in the SharePoint DateTime field.
- User loads form, and clears out the date in the DateTimeControl and hits submit.
- Date is saved as April 1, 2011 (Today’s date).
We don’t want it saved as Today’s date, we want it saved as blank. To get around this, we constantly have to check whether a value is entered using the IsDateEmpty property, and if so, handle the save appropriately. See my code sample below for an example of this.
if (!dateControl.IsDateEmpty) { item["Deadline"] = dateControl.SelectedDate; } else { item["Deadline"] = null; }
Because I don’t write nearly enough on this topic, I figured why not add another post about the splendid PeopleEditor control for SharePoint. Actually, these posts happen to be among my most popular. So popular in fact, that they are constantly being stolen and posted on other blogs without so much as a courtesy ping back! I won’t point any of those users out as they don’t deserve any precious link love. However, if you come across a PeopleEditor post that looks suspiciously like mine, I’m the original author!
Ok, so now that my rant is over, let’s go over a new trick I recently discovered when working with the PeopleEditor. Whenever I’ve worked with this control in the past, I’ve usually only dealt with SelectionSets that are limited to Users. So there has never been a need to handle entries where groups are specified. In case you are not familiar, here is a listing of the possible options for the SelectionSet property, posted by Alex and Ozaki on the MSDN PeopleEditor.SelectionSet Page – Community Section:
- User = single user
- DL = AD distribution list
- SecGroup = AD security group
- SPGroup = SharePoint group
I came across this requirement recently. More specifically, I needed to be able to save both users and groups, but obviously the logic for saving those is a little different. So we need a mechanism that helps us determine what type of entity a user has provided and based on that, process the correct save method.
So, let’s say we have a PeopleEditor defined as follows:
<SharePoint:PeopleEditor ID="peManager" runat="server" MultiSelect="false" Width="200px" AllowEmpty="true" SelectionSet="User,SPGroup" />
Now we want to save whatever the user enters into a column of type Person or Group that can accept both users and groups.
foreach (PickerEntity entity in peManager.ResolvedEntities) { switch ((string)entity.EntityData["PrincipalType"]) { case "User": item["Assigned"] = SavePeopleEditorControl(peManager.CommaSeparatedAccounts); break; case "SharePointGroup": SPGroup group = web.Groups[entity.EntityData["AccountName"].ToString()]; item["Assigned"] = group; break; // add additional case statements for the other SelectionSets } }
There you have it. Enjoy!
