November 10, 2010 Update: I’ve posted the sequel to this post: Autopopulate a SharePoint Form from URL (with SPUtility.js). I’ll leave the original intact just in case someone wants it, but I would highly recommend checking out the new and improved way using SPUtility.js!
August 20, 2010 Update: The code below has moved to be part of a bigger library… check out SPUtility.js on CodePlex!

Original Post:
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.

» Read more…

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.

» Read more…

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.

» Read more…

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:

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…
» Read more…