I also took this opportunity to improve a process I have to do all the time: what are the internal column names in a list? To get the list information, I built a simple AJAX app that consumes the Lists.asmx web service. Please keep in mind that this code will have be uploaded into SharePoint in order to work (a document library will work) and will not run from your desktop.
November 10, 2010 update: I’ve posted the sequel to this post: Autopopulate a SharePoint Form from URL (with SPUtility.js). I highly recommend checking out the new and improved way using SPUtility.js!
This post builds off of my previous post about making fields read only. In this case, I needed to autopopulate the NewForm.aspx with a value that gets passed to the form via URL parameters.
The goal of this post is to provide an easy to understand example of how to enable editing in an SPGridView. In this case, my datasource of choice is a SharePoint list.
The way that I chose to implement editing in an SPGridView involved two classes:
The main advantage for splitting the two classes is to separate all of the business logic into one class. Ideally, you should be able to completely change how the SimpleLogic class retrieves/updates data without changing the SimpleSPGrid code.
If you’ve done any work with SharePoint and SPAuditEntry, you may have noticed the distinct lack of Create event. Instead, two Update events are created which means some extra processing is required.
Add this to the list of things every SharePoint developer should know (up there with disposing SPWebs and SPSites). In general… Don’t update SharePoint objects on a GET request Call SPUtility.ValidateFormDigest() before anything on a POST request Here are the two links to read: What you need to know about AllowUnsafeUpdates (Part 1) What you need to know about AllowUnsafeUpdates (Part 2)
**May 20, 2010 Update
My problem started with a simple change to a site column. I had originally created a Country field with the following values:
After a change in requirements, the new values for the field were:
After updating the site column, I then needed to update the hundreds of items in the list to use “United States” instead of “US”. Instead of updating hundreds of items manually, I decided to write a small web services console app. (I was also not able to update it in datasheet… due to content approval maybe???)
However, I quickly ran into problems when attempting to update the multi-select choice field.
May 20, 2010 Update
If you are looking for a great example on how to create an SPGridView, check out Erik Burger’s blog:
This post is really meant to supplement part 2 of Erik’s guide and address values in the grid that include apostrophes when using filtering.
The SPGridView is one of the most useful SharePoint controls. You can use it to do sorting, grouping, and filtering just like the out of the box List View Web Part does for regular lists and libraries. This makes it relatively easy to create a custom grid with your own data. Unfortunately, filtering with the SPGridView is a little quirky, especially if your data could potentially contain apostrophes.
The most recent problem I ran into was when I tried to filter out items that had a certain Workflow status in the list. More specifically, I was trying to filter on items that had errored out and had a status of “Error Occurred” in the list.
I recently ran into a problem creating alerts in a web part for the current user. After the alert was added, no matter what I set the SPAlert’s EventType to, it always defaulted to All. I finally figured out a way around this problem thanks to a helpful post by erwin at sharepointology.
While researching a bug with editing in datasheet view and a custom list event handler, I discovered strange behavior with boolean values. Any boolean value you get from the SPItemEventDataCollection depends on where the item was originally edited: either using the regular user interface (EditForm.aspx, NewForm.aspx) or using datasheet view.