in

SharePoint Blogs

The Best Place for SharePoint-related Blogs

Aaron Robertson-Hodders SharePoint Blog

May 2007 - Posts

  • The solution to saving properties in Custom Field Types!

    I have finally managed to put Anton's code to the test in my own custom field type with great results.

    The underlying issue is that the Update method does not seem to get called when adding a new field, and because there are a number of initializations of the field object the values in the custom propery editor controls get lost before you get to the OnAdded event where you could set them!

    So, Anton's plan (which I confirm works very well) is to store the values of the properties in a static string dictionary, keyed with the hash of the current SharePoint context SPContext.Current.GetHashCode() so we get the right property back out in the OnAdded event and can set the correct values.

    You can get the full code in the thread linked to above, but I'll summarize as best I can. I'm using a property called Application that is set by selecting a value from a combo box - which is actually part of a parent child combination used in the Property Editor, but that's another story...

    First we create a new dictionary in the Field Class (the one that inherits from the SPField... class) to store the properties:

    private static Dictionary<int, string> updatedApplicationProperty = new Dictionary<int, string>(); 

    Create a new method that the Property Editor Control can call to update the dictionary to the value in the property editor control:

            public void UpdateApplicationProperty(string value)
            {
                updatedApplicationProperty[ContextId] = value;
            } 

    Then, in the get for the property, return the dictionary stored property value if it exists or the internal value if not:

    public string Application

    get

    {

                    if (updatedApplicationProperty.ContainsKey(ContextId))
                    {

                        //If we saved a value away and we're in the middle of the save field process, then pull it out.
                        return  updatedApplicationProperty[ContextId];
                    }
                    else
                    {

                        //Return the existing value for the application property. This will be the case if we already have a field.
                        return sApplication;
                    }

    }

    In the Update method of the Field Control set the custom property value and remove the stored property value:

    this.SetCustomProperty("Application", this.Application);

    if (updatedApplicationProperty.ContainsKey(ContextId))
         updatedApplicationProperty.Remove(ContextId);

    And, lastly, in the OnSaveChange event in the class for the Property Editor Control store the value of the control that represents the property into the dictionary via the Update...Property method for a new field, or set the property as normal if the field already exists:

                    BDCField currentBDCField = field as BDCField;

                    if (isNewField)
                    {
                        currentBDCField.UpdateApplicationProperty(this.cboApplications.SelectedValue);
                    }
                    else
                    {
                        currentBDCField.Application = this.cboApplications.SelectedValue;
                    }

    Hopefully that's a reasonable description of the required steps. Anton has a good description of the why he chose the static dictionary in the forum post.

     Thanks again Anton and sorry it took me sooooo long to try it out!!!

  • Adding additional properties to the MOSS People Search

    I figured out how to add additional fields from the Profile Import into the People Search today.

    This requirement occured to me after discussing how this might be done with Aaron Saikovshi at the APAC SharePoint Conference.

    In this particular case, I wanted to add one of the extended properties from the Exchange Users into both the Search Box control and the results page. I suspect, but have not confirmed that this process would work for extensions to the AD Schema too.

    There are several steps to make this happen:

    1. Assuming that you have a property with data in it, go to the Shared Services Administration page and click on 'User Profiles and Properties' link.

    2. Add a new Profile Property for the property you want to include by clicking the 'Add profile property' link at the bottom of the page. The things to pay attention to are the policy settings (properties will need to be available to all those who need to see them!) and the Property Import Mapping (you need to map your property to a physical property crawled by the indexer - just like Managed Properties in MOSS Search - which is actually what this property becomes). In the case of my Exchange extended property this was extensionAttribute1.

    3.  At this point I did a full import, just to make sure I could see the values coming through when I viewed the user profiles.

    [Ishai has a nice post with pictures for the remaining steps...]

    4. Go to the people search page in the Search Centre (or wherever you put the people search).  Edit the page and then edit the properties of the People Search Box. Open the Properties property and add a new Property element to the list, eg:

    <Property Name="NewProp" ManagedName="NewProp" ProfileURI="urn:schemas-microsoft-com:sharepoint:portal:profile:NewProp"/>

    where NewProp is the name you gave to the new Profile Property above.

    5. In the Results Query Options section of the properties for the People Search Core Results web part, edit the Selected Columns property. If your default value is like mine, it will look like there is nothing in there - which tricked me for a while, but click the ... button and add a new Column element for your property equal to the name of your new Profile Property.

    6. Edit the Data View Properties of the People Search Core Results web part to add the new column (in lower case), somewhere in the XSL eg. <xsl:value-of select="newprop"/>. Click Apply and Publish (if you have content management turned on). Don't worry if you get a nasty looking error in the web part unless it happens after you publish! You did backup the XSL before you modified it, right?!

    I also had to do some crawling of the Content Sources once I had added the new Property and at one point had to reset and re-crawl. I think there is something strange going on there, because the first property I added only seemed to require a Crawl to be available, but the second would not work as a Selected Column until I reset and re-crawled! I'm not 100% on what requires what level of crawling. I can understand a full crawl being required for new properties because that probably updates the property store, but a Reset Crawled Content?!

    If anyone has, or tries to get this working with a custom Active Directory column it would be great to know and complete the puzzle!

     


Need SharePoint Training? Attend a SharePoint Bootcamp!

Posts (c) their respective authors. Everything else (c) 2007 SharePoint Experts