Andrew Richter's Professional Blog

Friday, February 13, 2009

Correction - Customized Input Forms: The JavaScript Approach

Previously I posted about my method for customizing SharePoint list forms (NewForm.aspx, DispForm.aspx, EditForm.aspx). Recently, an issue has come up with respect to this code and saving list items.

If a user is modifying a list item, and they have disabled controls on the page (grayed out), then when they save the item, those disabled fields will revert to the default value specified for each of those columns. The correct values populate on the page, but apparently the values stored within disabled controls do not get returned to the server upon the form being submitted.

I have come up with a quick solution (not sure if it is the best at this moment), but it allows for the values to be returned to the server by re-enabling all of the disabled fields just before the form is submitted. Only problem so far is that if the page takes a while to submit, the fields appear to be editable to the user, even though changes made won't actually be sent to the server.

Please see this link for a reference to the function PreSaveAction(): Add JavaScript Date Validation into List Item forms

Updated code (new code added is highlighted in yellow): CustomizedInputForms_JavaScriptFile

Enjoy!
--andrew

MOSS Cascading DropDownLists - The Sexy Approach - 2 of 2

Disclaimer reiterated: Do NOT copy/paste all of this code and deploy straight to a production environment. I cannot stress this enough.

Link to previous post: MOSS Cascading DropDownLists - The Sexy Approach - 1 of 2

Welcome to the second half of my discussion about AJAX Cascading DropDownLists within SharePoint 2007. I apologize for not getting this posted earlier, but I've been swamped at work lately. There is a lot of code involved, and I would like to thank the following people for various bits and pieces which I borrowed (links to my code are at the bottom of the post):

Todd Bleeker: Custom Field Control discussion at SharePoint Best Practice Conference 2007
an extremely informative and helpful introduction to the various components of a custom field control
DataCogs: Sharepoint – Cascading Drop Down Lists
an excellent example of a custom field control, especially one solving the same problem I was looking to solve
Wouter van Vugt: Creating a Windows SharePoint Services 3.0 Custom Field by Using the EntityPicker
an excellent explanation of the problems associated with saving a new field control instance for the first time, and how to correctly save the properties.

As the manifest.xml and wsp_structure.ddf files are pretty straightforward if you've worked with SharePoint Solution packages before, I will not discuss these.

Here is a great walkthrough on the different elements required in creating a custom field type on MSDN: Walkthrough: Creating a Custom Field Type.

We'll start with the creation of the field type definition: fldtypes_cascadingdropdownlist.xml. This file is used to store the various configuration information related to your custom field type. Multiple field types can be defined within the same file, however, this is not advised. All of the fields at the top are standard custom field type definition attributes.

TypeName is the internal name for this field type
TypeDisplayName is what will be displayed on the "Create a new column" page
FieldTypeClass is where you reference the assembly containing your field type class
FieldEditorUserControl is the location of the ASCX file which defines the user interface for Custom Properties
PropertySchema is used to define custom properties.
All of my custom properties are simple TEXT fields, which have fixed length and are hidden. This is so I can use other controls (like DropDownLists) for the creation of the column, to make selecting values easier on the user. These custom properties are where I store which list supplies the data and how it is displayed/filtered.
RenderPattern is not used in my solution.

The class and assembly referenced in the attribute FieldTypeClass is used as the base class for storing/retrieving custom and default properties for this field type. Please see the comments in CascadingDropDownList.cs for a more detailed breakdown of functionality. I have opted to use the ThreadData method for storing values on initial column creation as mentioned previously in the MSDN article by Wouter van Vugt.

In CascadingDropDownList.cs near the bottom, I am using the custom class CascadingDropDownListEditControl as the RenderingControl. The user control for this is incredibly simple: CascadingDropDownListEditControl.ascx. It is just a normal DropDownList inside of a SharePoint RenderingTemplate. The class file associated with this ASCX file is CascadingDropDownListEditControl.cs. There are a few key components of this class to note:

ddlCascading.ContextKey is used to pass the necessary information to access a SharePoint list to the Web Service which will be populating the DropDownLists on the client side.
ddlCascading.ParentControlID has to be set at runtime, as this is the ID of the control on the page, not the value stored within the column's properties.
Render method is overridden to circumvent the necessity of disabling EventValidation for the CascadingDropDown extender to function. This method obtains all possible values from the corresponding SharePoint lists, and registers them for event validation on the client side (potential performance hit if you have significantly large value lists).
ddlCascading.ServicePath is the location for the web service to pass the AJAX request to and ddlCascading.ServiceMethod is the method invoked within the given Web Service.

This web service is defined within the files CascadingWebService.asmx and CascadingWebService.cs. The ASMX file is very simple, with just a reference to the assembly containing the web service class. Within the class, there are two functions: GetListItemsPageMethod and SortNameValuePair. The name for GetListItemsPageMethod can vary as long as it is the same here as it is in CascadingDropDownListEditControl.cs for ddlCascading.ServiceMethod. However, the *signature* for this method must be exactly as displayed. The contextKey at the end is optional (if you don't have to supply additional information for the AJAX request), but the rest of the parameters, as well as the security modifier and return type must be the same as I've used. SortNameValuePair, on the other hand, is a custom function I created to allow for sorting the collection of CascadingDropDownNameValues, since List.Sort does not know how the name-value pairs should be compared.

And the final component to this solution is the Properties class for the Cascading DropDownList. The Properties class is used for defining the way in which custom list properties (specified within the field type definition fldtypes_cascadingdropdownlist.xml) are displayed on the column creation/modification page. Again, please reference the comments within CascadingDropDownListPropControl.cs for a description of what is happening. It displays and modifies the custom column properties (which are defined as TEXT elements) using a Text Box, a Button, and several DropDownLists. CascadingDropDownListPropControl.ascx is a little more involved than the other ASCX files, but much of the HTML was simply to ensure that the properties for this custom field control looked like the properties for out-of-the-box field controls.

For the Name/Value columns, the source SharePoint list needs to be established as follows:

For each Cascading DropDownList you plan to have, you need a column to represent its potential values.
Be sure to enter all possible values for Parent, Child, Grandchild, etc within each list item
Here is a picture of my sample list: Bird Classifications

I tried to supply a lot of code, with the hope that it would be self-explanatory. If you need further explanation of what is happening, or why I did it this way, please do not hesitate to comment below. Here are some pictures of a sample implementation for Bird Sightings, using 3 Cascading DropDownLists (Family[Parent] -> Genus[Child] -> Species[Grandchild]):

Limitations:

The Cascading DropDownList controls must be displayed in order on the page, in the order you want their relationship to be (Parent before Child, and Child before Grandchild, etc.) If the Child is before the Parent, then the Child control will not be able to find the Parent control on the page.
It is possible to modify the Parent field of a Cascading DropDownList to a control which appears lower on the form page. The filtering of values in the "Parent Column" property only removes the current field.
If you have a Parent->Child->Grandchild relationship, and different Parent values have the same Child values in the source SharePoint list, then all of the potential Grandchildren for each Child will be visible if that Child is selected, regardless of which value is entered into Parent.

This control has already received widespread use within my organization. If you have any recommendations on improvement to remove these limitations, I would love to hear about the modifications you have made to the below code. I hope you enjoyed this deep-dive into employing the AjaxControlToolkit's CascadingDropDown within SharePoint using a Custom Field Control.

Enjoy!
--andrew

Links to solution files:

Tuesday, December 9, 2008

MOSS Cascading DropDownLists - The Sexy Approach - 1 of 2

Disclaimer: I recommend reviewing any/all code (including content that is linked to) and fully understanding what it does before deploying anything to your staging, test, and/or production environments. There is nothing worse than deploying code/solutions which cause critical errors that you don't know how to fix.

Link to next post: MOSS Cascading DropDownLists - The Sexy Approach - 2 of 2

I am really excited about this post for a number of reasons:

AJAX makes things look really slick
Cascading DropDownLists in SharePoint are a pain
I've finally finished this project!

The task at hand was to implement Cascading DropDownLists within a standard SharePoint list (no InfoPath). Some resources that were immensely helpful while constructing this are as follows.

Regarding Custom Field Controls and Cascading DropDownLists:

Data Cogs - SharePoint Cascading Drop Down Lists
MSDN - Creating a Windows SharePoint Services 3.0 Custom Field by Using the EntityPicker

Regarding AJAX integration with SharePoint:

Mike Ammerlaan - Integrating ASP.NET AJAX with SharePoint
Rich Finn - Ajaxify MOSS

The project consists of two solutions, one which configures the web.config with modifications to allow ASP.NET AJAX, and one which deploys an AJAX Cascading DropDownList custom field control. This post will cover the integration with AJAX. My next post will cover the custom field control.

Prerequisites:

You must have .NET Framework 3.5 SP1 installed on your server
You must add the AjaxControlToolkit DLL to your VS solution

These are links to the four files (Feature.xml, manifest.xml, wsp_structure.ddf, AjaxControlToolkitSupportInstaller.cs) which are necessary for the solution which enables AJAX on your web application. I have decided to host the files within my GoogleDocs account because I like color coded files, there is too much code to paste it into this blog window, and I don't feel like creating a CodePlex project to upload, maintain, track bugs, and such.

If you are familiar at all with SharePoint Solution deployment, you will be right at home with manifest.xml and wsp_structure.ddf. I did not use any 3rd party tools for solution deployment. I used a simple C# class library with some custom batch files for processing the wsp_structure.ddf.

Please note: You *must* create two GUIDS: one for the solution, and one for the feature. Also, be sure to create your assembly with a strong name, and insert your PublicKeyToken into the Feature.xml file.

I took bits and pieces from both Rich Finn's CodePlex project and Mike Ammerlaan's blog to create this feature. However, I really liked the way that Ted Pattison implemented a SPWebConfigModification feature in his post Using a Web Application Feature to Modify web.config, so instead of Ajaxify MOSS's command line approach, this is entirely browser based, and activated/deactivated within Central Administration on the "Web Application Features" page. Speaking from experience, be sure you have the correct web application selected before you activate the feature.

Part 2 to be coming shortly.

Enjoy!
--andrew

Links to solution files:

Friday, December 5, 2008

.Net Framework 3.5 SP1 and SharePoint Search/InfoPath/Etc.

Recently, I installed .NET framework 3.5 SP1 onto my production SharePoint WFE after thoroughly testing a new AJAX based field control I had developed. In my staging and development environments, I encountered no issues with the framework itself, however, once I installed on production, a couple issues arose:

Administrator approved InfoPath forms with custom code were causing errors (no indication of what the error was)
Search Service was failing to crawl content with the error "Access Denied."

After some Googling, I came across a MS KB article , and an MSDN blog both referring to a security feature in IIS 6 called "loopback check." This feature was added (also present in IIS 5.1) to prevent reflection attacks on the server. Please see the blog entry by jiruss for more information on this feature.

Of the two workarounds listed, either disabling the loopback check, or modifying the host names specified in the registry, I believe modifying the host names to be the best solution. I agree with jiruss in that completely disabling the loopback check increases the attack surface area of your system, and should be avoided.

The actual modifications I made were to add the URL/host headers/AAM mappings for my various sites (main portal and mysites were the only two that did not use the machine name in AAM) to a newly created "Multi-String Value" registry key called BackConnectionHostNames (each entry on a separate line) at the registry path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

Hope this helps any people experiencing "Access Denied" related issues after installing .NET framework 3.5 SP1.

Enjoy!

--andrew

Monday, July 28, 2008

Customized Input Forms: The JavaScript Approach

Correction [02.13.2009]: I have recently been informed of an issue with field values not saving when they are disabled for the user. Please see my post here for updated code.

If any of you have had to customize the input forms for lists or libraries in SharePoint, you'll know that it is not easy. You can customize the form with a custom list form web part, but you better not delete the original list form web part, otherwise your list gets hosed. You can have both on the page (with the original web part hidden), but then you lose attachment support with JavaScript errors. If you create a new page without the original list form web part, then you get a nice JavaScript alert saying that the form has been customized to not allow attachments. If you used the custom list form web part, then you might find it cumbersome and tedious to make changes when new columns are added. I have tried countless recommendations for modifying the list input form, and none of them really seemed to work cleanly and effectively. Until I stumbled across the forum discussion located here on MSDN Forums.

Of all of the ideas proposed in this forum topic, I found tscheifler's usage of JavaScript quite intriguing. There were some limitations that I found when implementing their exact solution (most notably around disabling columns of type: Lookup, Date and Time, and Multiple lines of Text). Extending this, and incorporating various other bits of information lying about the web, I ended up with a solution I am quite happy with. This assumes you have an existing list with several fields you would like to hide/disable for certain user groups. We will begin by modifying the "NewForm.aspx" page, but these steps will work for any of the input forms:

Open the "New Form" for the list and remove all query string variables (should end up with http://server/site/listname/NewForm.aspx)
Append "?ToolPaneView=2" onto the end of the url (http://server/site/listname/NewForm.aspx?ToolPaneView=2)

Note: this places the page into "Add a Web Part" view
Add a new "Content Editor Web Part"(CEWP) to the page after the existing web part

Modify the source view of the CEWP to include this code:

<SCRIPT LANGUAGE="JavaScript">
<!--
function disableChildren(currentElement)
{
if (currentElement)
{
if(currentElement.tagName == "IFRAME")
{
frm = window.frames[currentElement.id].document;
disableChildren(frm.getElementsByTagName("html")[0]);
}
var i=0;
var currentElementChild=currentElement.childNodes[i];
while (currentElementChild)
{
disableChildren(currentElementChild);
i++;
currentElementChild=currentElement.childNodes[i];
}
if (currentElement.tagName)
{
currentElement.setAttribute("disabled", "true");
currentElement.setAttribute("contentEditable",
"false");
currentElement.setAttribute("onclick", "");
currentElement.removeAttribute("href");
}
}
}

function hideRowsAfter(currentRow)
{
row = currentRow.nextSibling
while (row)
{
row.style.display = "none";
row = row.nextSibling;
}
}

function findControl(FieldName, opp)
{
FieldName = "FieldName=\"" + FieldName + "\"";
//get all comments
var arr = document.getElementsByTagName("!");
for (var i=0;i < arr.length; i++ ) 
{
// now match the field name
if (arr[i].innerHTML.indexOf(FieldName) >= 0)
{
switch(opp) 
{
case 0:  //disable all children
disableChildren(arr[i].parentNode.parentNode);
break;
case 1:  //hide row
arr[i].parentNode.parentNode.style.display="none";
break;
case 2:  //hide all rows after current
hideRowsAfter(arr[i].parentNode.parentNode);
break;
default:
break;
}
}
}
}

function disableControls(inputArray)
{
for (var i=0; i < inputArray.length; i++)
{
findControl(inputArray[i], 0);
}
}

function hideControls(inputArray)
{
for (var i=0; i < inputArray.length; i++)
{
findControl(inputArray[i], 1);
}
}

function hideControlsAfter(input)
{
findControl(input, 2);
}

//Usage:
// disableControls(["Field Name 1", "Field Name 2"..]);
// hideControls(["Field Name 1", "Field Name 2"..]);
// hideControlsAfter("Field Name");

//-->
</SCRIPT>

Follow the "Usage notes" to add calls to the disableControls, hideControls, or hideControlsAfter functions which will modify the fields displayed on the page

Note: you can find the values to put in place of "Field Name 1" and "Field Name 2" by viewing the source view for the page and searching for: FieldName="
The value within the double quotation marks will be what you enter inside the arrays in the hide/disable function calls.
In the CEWP's tool pane, add security groups or audiences which should have the fields hidden/disabled to the "Target Audience" setting
Save the web part properties, and click the "Exit Edit Mode" link in the upper right below "Site Actions".

Now you should see all of the fields hidden or disabled based on your security settings specified within the CEWP.

To extend this into a more reusable solution, I created a custom CEWP with this JavaScript code, exported it to a .dwp file, and then uploaded it to the Web Part gallery. Then, the only modifications needed are to add this web part to the page (under ToolPaneView=2 view), add the "usage" functions, and add the security groups to the targeted audiences.

This solution now hides/disables fields specified within the original list input form, which retains the attachment functionality, while being able to easily make modifications when new fields are added/modified based on column ordering.

However, there are some limitations to this method. None of which were show stoppers for me, since this method is very easy to undo (simply remove the CEWP from the forms). Especially in the interim until Microsoft is able to fix this little problem and offer a clean, efficient, and effective method of customizing input forms. These limitations are:

Security groups or audiences need to be created for the group of users which should have limited access to list fields, which excludes the users with access to the restricted fields.
You cannot make any of the hidden/disabled fields required unless you specify default values, as the fields will still remain on the page and submit data, they are just hidden to the user
If the user employs firebug or other plugins which can alter JavaScript, they could unhide/undisable the fields you removed and then manipulate the data
Information in these fields is still visible to users if the columns are displayed within list views, as well as Source View of the input form

Enjoy!
--andrew

Thursday, April 10, 2008

Comparing InfoPath Fields - Case Insensitively

Currently have a form deployed which has 4 different views:

User
Manager
Process Owner
DBA

Each of the first three users (User, Manager, Process Owner) have an authorization field with an automatically filled in date field. Each user can only read/write for their authorization, and have read access to the authorizations below them (User cannot see anyone else's, Manager can see User's, Process Owner can see Manager's and User's, DBA can see all).

A problem arose where the Process Owner was actually the user's manager as well, but my rules for determining which view is presented to the user only showed this person the Process Owner view. I did not want to create a new view just for the case of Process Owner == Manager, so I did the following:

Set the Manager's authorization field to Read/Write on the Process Owner view
Added a conditional formatting element to the Manager's authorization field to set it to read only when the managerID field does not equal the InfoPath function "userName()"

This was great, except everything is case sensitive, and there is no standard "toUpper" or "toLower" functions to standardize multiple fields on one case...enter translate.

The resulting expression used in my conditional formatting is (broken onto multiple lines for ease of reading):

translate(
  substring-after(
    /my:myFields/my:grpEmployeeInformation/my:managerID,
    "\"),
  "ABCDEFGHIJKLMNOPQRSTUVWXYZ",
  "abcdefghijklmnopqrstuvwxyz") !=
translate(
  xdUser:get-UserName(),
  "ABCDEFGHIJKLMNOPQRSTUVWXYZ",
  "abcdefghijklmnopqrstuvwxyz")

Rather long and cumbersome, but you can see both the left and right hand sides of the "!=" translate all capital letters to their lower case equivalents. The substring-after() bit was just an artifact of the structure of my form, where the managerID field is in the format of "domain\username".

Note: Since this form uses the "userName()" function, it will probably require full trust.

Enjoy!
--andrew

Wednesday, April 2, 2008

DataView Web Parts and Page Layouts

The DataView Web Part is a nice tool to customize the way information is presented on a page. Unfortunately, this web part is not available through the browser's "Add Web Part" interface, and must be added through SharePoint Designer. The problem I ran into was that pages attached to a page layout cannot be directly modified within SharePoint Designer.

I decided to detach the page from its layout and add the DataView Web Part. Everything seemed to work, except I started to receive errors stating "This Web Part Page has been modified since you opened it." I figured this was related to detaching from the Page Layout (I may have hosed something up unknowingly). I then reattached the page to its layout and everything ended up working fine.

Therefore, if you need to add a DataView Web Part to a page attached to a layout, I suggest doing the following(all done within SharePoint Designer):

Detach the Page from the Page Layout
Go through the necessary steps to add a DataView Web Part to an existing zone on the page
Reattach the Page to it's Page Layout

This was fantastic since detaching/reattaching to layouts does not change any web parts or customizations made to those web parts. Also, once the DataView Web Part is on a page, you can simply modify it's display through the browser using the XSL editor.

Note: I have not attempted to reattach a page to a layout after new zones have been added and do not know exactly what will happen.

Enjoy!
--andrew