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!

Working with JavaScript can definitely be painful, but I always love stumbling across interesting and strange features of the language. I just found wtfjs.com which led me to these two answers on stackoverflow.

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.

In this era of Web 2.0 web applications, I think it was only a matter of time before I needed to investigate how I could apply AJAX to SharePoint. With a little JavaScript and SharePoint’s web services, you can build fancy apps that can easily be dropped into a document library. And after reading Glen Cooper’s blog post on the subject, I figured it was something definitely worth investigating.

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:

• SimpleLogic – handles query and update operations
• SimpleSPGrid – handles all of the setup for the ObjectDataSource and the SPGridView

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.

I was developing an input form for a search when I came across the need to allow the user to filter items using a date range. I had two input boxes where the user could enter a start and an end date. For some of the most common date ranges, I decided to create links that could be clicked to auto-populate the start/end date textboxes. For example, searching for items that were created last week or last month. Using JavaScript’s Date object, I was able to put together some nice examples.

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…

1. Don’t update SharePoint objects on a GET request
2. 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…