SPUtility.js is a library used to get/set SharePoint’s form fields. We can also use it autopopulate a Newform/Editform based on some URL parameters which are passed to the page!
I recently got asked if it was possible wrap the column headers in a list view web part. The user had a WebPart with quite a few columns with long names and was trying to prevent the page from scrolling left to right.
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)
Two identical custom lists with the same columns. The only difference is that one list has columns added using Site Columns and the other list had columns added directly to the list. The same? Not so much…
**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.