When developing custom WebParts and UserControls for SharePoint you often need to access Lists and their content. There is a number of ways to retrieve a List (or more specifically, a SPList instance). For example, if you know the List’s ID (which is a Guid) you can do the following:

SPList list = SPContext.Current.Web.Lists[someGuid];

Which works fine. But SharePoint also provides a sometimes very convenient shortcut, namely SPContext.Current.List and SPContext.Current.ListItem. These contain, respectively, the currently selected List and the currently selected ListItem. But where do these get their values?

One word. Magic.

No, not really. But it’s one of those “hidden features” that can make your life a whole lot easier.

I had a requirement for a project to display a custom DetailsView (similar to DispForm.aspx, EditForm.aspx and NewForm.aspx) for an Item selected via my ASPGridView (through a MenuField, which I will discuss in Building A SPGridView Control – Part 3. Promise). I already knew about the ListFieldIterator so using that seemed the way to go forward. In the markup for the ListFieldIterator I can set the ListId and the ItemId and everything will take care of itself. But again, where do these IDs come from?

One word. The query string.

Ok, that’s two words but you get the point. Have you ever noticed that if you go to List Settings, the url looks something like this?

http://mossvm/_layouts/listedit.aspx?List=%7B345C0885%2DA30C%2D471F%2DAB93%2DEC0C6C49FE14%7D

And that if you view an Item in a List, your url looks something like this?

http://mossvm/Lists/Links/DispForm.aspx?ID=1

Under the hood, the List and ID parameters are used to set the values of SPContext.Current.ListId and SPContext.Current.ListItemId/ItemId. And these in turn cause SPContext.Current.List and SPContext.Current.ListItem/Item to be populated (provided the IDs actually exist, of course).

To demonstrate this I put together a very simple WebPart using the following code:

protected override void RenderContents( System.Web.UI.HtmlTextWriter writer )
{
    Guid currentListId = SPContext.Current.ListId;
    if ( currentListId == Guid.Empty )
    {
      writer.Write( "No list ID" );
    }
    else
    {
      writer.Write( String.Format( "List ID is <b>{0}</b>", currentListId ) );
      writer.WriteBreak();
 
      SPList currentList = SPContext.Current.List;
      writer.Write( String.Format( "List title is <b>{0}</b>", currentList.Title ) );
    }
    writer.WriteBreak();
    writer.WriteBreak();
 
    int currentListItemId = SPContext.Current.ItemId;
    if ( currentListItemId == 0 )
    {
      writer.Write( "No list item ID" );
    }
    else
    {
      writer.Write( String.Format( "Item ID is <b>{0}</b>", currentListItemId ) );
      writer.WriteBreak();
 
      SPListItem currentListItem = SPContext.Current.ListItem;
      writer.Write( String.Format( "Item url is <b>{0}</b>", currentListItem["URL"]) );
    }
    writer.WriteBreak();
}

Using this WebPart without a query string:

qsm1

And with a query string:

qsm2

Pretty neat huh? Even better, when you use any SharePoint control (like the ListFieldIterator) in your WebPart, it will render against the values provided in your query string. So if I provide the ID of my Contacts List, the ListFieldIterator will render those fields. If I provide the ID of a custom List it will render those fields. Etc.

It gets better. I mentioned that I needed to provide editing as well. The ListFieldIterator actually understands editing and will render a field’s EditPattern when asked. So how do we ask? Through the query string, of course! If we add the Mode parameter with a value of Edit we’ll set the ControlMode property which the ListFieldIterator (and again, any SharePoint control that derives from FormComponent) uses the determine what to render. Other values for the Mode property are Display and New. So by setting a single property I can have the same ListFieldIterator render an Item in Edit, Display or New mode, where New shows an empty form (and consequently ignores the ID parameter).

I understand that this was a bit of a whirlwind introduction to what you can make SharePoint do using the query string but I did not want to go into too much detail on how to use the ListFieldIterator, for example. That would be more than enough to fill a seperate post. But I still hope I’ve given you something to add to your toolbox.

If you liked this post, please click on one of the advertisements below. Thanks!


0 Responses to “SharePoint Query String Magic”

  1. No Comments

Leave a Reply


*