The XML from the Permissions GetPermissionCollection web service looks something like:

The main heartache I had when trying to use XPATH was that the XML uses a default namespace (the xmlns=”" part). In order to select the Permission nodes, you need to use a XmlNamespaceManager:

Here is another example on Stackoverflow.

Let’s use the same example, but this time take advantage of SPUtility.js (the open source JavaScript library I maintain).

Our page’s URL would be something like:

/Lists/ProjectTasks/NewForm.aspx?projectID=523

I want to take the ‘projectID’ URL parameter and autopopulate my Project ID field with this value. Then, we’ll make the field read only.

We’ll dive right into the code:

To install, you’d simply place the JavaScript above into a Content Editor Web Part on your NewForm.aspx or EditForm.aspx. Take a look at the SPUtility.js Installation page for detailed instructions.

The first answer made me realize that undefined is not a keyword in JavaScript; it actually is a type that also happens to have a global variable with the same name. This means that you can change the value of undefined (the global variable) to be something else.

And, like shown above, the correct way to check if a variable is undefined is by using typeof.

The second feature, is something that I often used but had no idea why it actually worked: void(0).

According to Breton’s excellent explanation, void is actually a prefix operator. When you prefix any expression with void, the result evaluates to undefined. So, using our correct method for checking undefined above you get this in the console:

Awesome!

What we needed to do was wrap the column header so that it fit more to the data in the grid.

The solution is relatively simple to implement; all you need is a Content Editor Webpart at the bottom of the page somewhere with the following JavaScript in it:

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.

Step 0: HTML for user input and displaying results

Since I will be calling the GetList method on Lists.asmx, I will need two parameters from the user: Site URL and List Name. Site URL gives the web service context to a particular web and List Name should be a list within that web. I also specify a DIV which is where I will display the list’s information.

Now that we have our HTML form, we can work on the JavaScript code.

Step 1: Building a SOAP Message

To communicate with the web service, we need to use SOAP. Luckily, Glen has already created a very handy class for taking care of these operations. It is also reusable so it will come in handy for other web service calls. I tweaked his code a little bit and then put it into SoapUtils.js (also, please note this code depends on Prototype.JS):

This utility class handles a lot of the grunt work for creating the SOAP message. It makes it pretty easy to grab the input, build the message, and then send it to the server. Next, I need to give it the specifics it needs to build the actual message. This is all contained inside my Execute function:

The Execute method is then bound to the “Get Columns” button on page load:

Step 2: Parsing the Web Service’s XML response

At this point, we are ready to handle the response from the web service. Unfortunately, parsing XML using JavaScript was not exactly the easiest experience. I haven’t found an easy way to do it, so if you have any ideas, please let me know in the comments.

In any case, if an error occurs, I simply want to print the error message:

A success message is a lot more complicated since we want to extract information out of the returned XML. In fact, if you look at the entire response from the webservice after calling GetList, the returned result for a simple Images library is something like 1100 lines of XML. The majority of this is taken up by the full description of each column in the list. There is a LOT of junk that we are simply going to be skipping over. For sanity sake, I’m not going to post the entire response, but useful snippets of interest.

Overall, the response will look something like:

Notice, the List node contains a LOT of useful information. Once we have that node, we can display a lot of it using this function:

Also, since we are interested in the internal column names, we want information about each of the fields. All of the columns are listed inside the Fields node (see above). A lot of them have attributes similar to below:

So, for each of the Field nodes, we are interested in the StaticName and DisplayName attributes:

And finally, to bring it all together, we are calling these functions inside our success function:

All together now:

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.

In this case, the URL that gets passed in is something like:

/Lists/ProjectTasks/NewForm.aspx?projectID=523

I wanted to take the ‘projectID’ URL parameter and autopopulate my Project ID field with this value.

Additionally, we will make this field Read Only so that they can’t change the value. Lastly, do this all without SharePoint designer or C# code.

Stick the following code in a Content Editor on your NewForm.aspx or EditForm.aspx. (Remember you can get to edit mode by appending ToolPaneView=2 on the end, like NewForm.aspx?ToolPaneView=2)

Depends on Prototype.js.

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.

The Setup

In this example, our logic class is retrieving and updating data in a SharePoint list. My SharePoint list had three main columns: Title (text), Region (choice), and Total Sales (currency).

Now that I had some data to read from and write to, I was ready to create my logic class.

The SimpleLogic Class

The goal for the logic class was to expose all of the operations the gridview would need in order to read or update data:

1. public DataTable Select()
   How do I get the data?
2. public List<BoundField> GetColumns()
   How do I display the data?
3. public void Update(Dictionary<string, string> data)
   How do I update the data?

DISCLAIMER: When actually implementing the class above, you will probably need to add some sort of error handling. In order to provide a simpler example, the error handling has been omitted.

Once our logic class is functioning correctly, we can work on hooking it up to an SPGridView.

The SimpleSPGrid Class

The SimpleSPGrid class contains most of the guts that will probably be different to you. The first thing to notice is that it takes our SimpleLogic class as a parameter. This allows us to instantiate our logic class beforehand with any parameters that are needed, and then pass it into SimpleSPGrid to use.

Wrap up

Now that all the hard work is done, we are ready to use the classes inside our web part. Inside the CreateChildControls of your webpart you would have the following code ( even though we have an SPWeb here, it should NOT be disposed):

This will produce the following grid!

And clicking edit…

First, the setup. I needed two text boxes to hold the start/end dates and then wanted the user to click links to auto-populate them with some relative dates:

<a href="javascript: void(0);" onclick="return setRelativeDate('today')">Today</a>

<label for="txtStartDate">Start Date:</label><input id="txtStartDate" type="text" />
<label for="txtEndDate">End Date:</label><input id="txtEndDate" type="text" />

Then to figure out how to calculate the dates using JavaScript. Here are the examples.. starting out easy with Today‘s date. When creating a new Date object, it is automatically initialized to the current day and time:

var today = new Date();
txtStartDate.value = getShortDateString(today);
txtEndDate.value = txtStartDate.value;

Yesterday is Today -1:

var yesterday = new Date();
yesterday.setDate(yesterday.getDate()-1);
txtStartDate.value = getShortDateString(yesterday);
txtEndDate.value = txtStartDate.value;

This Week is a little more complicated. getDate() returns the day of the month (1-31) and getDay() returns the day of the week (0-6).

var thisWeek = new Date();
// set the date to most recent Sunday
thisWeek.setDate(thisWeek.getDate() - thisWeek.getDay());
txtStartDate.value = getShortDateString(thisWeek);
// set the date to last week's Saturday
thisWeek.setDate(thisWeek.getDate() + 6);
txtEndDate.value = getShortDateString(thisWeek);

Last Week is pretty similar to this week. I think the hardest part for me is the function names getDate and getDay. I always was getting them confused and thought that they should have been more specific… like getWeekDay and getMonthDay or something.

var lastWeek = new Date();
// set the date to last week's Sunday
lastWeek.setDate(lastWeek.getDate() - lastWeek.getDay() - 7);
txtStartDate.value = getShortDateString(lastWeek);
// set the date to last week's Saturday
lastWeek.setDate(lastWeek.getDate() + 6);
txtEndDate.value = getShortDateString(lastWeek);

The main difficulty I had with This Month was how to figure out the last day of the month. Luckily, if you can figure it out by selecting the first of next month and then subtracting a day.

var lastDayOfThisMonth = new Date();
// go to the next month
var nextMonth = lastDayOfThisMonth.getMonth() + 1;
lastDayOfThisMonth.setMonth(nextMonth);
// go to the last day of the previous month (this month)
lastDayOfThisMonth.setDate(0);
txtEndDate.value = getShortDateString(lastDayOfThisMonth);
lastDayOfThisMonth.setDate(1);
txtStartDate.value = getShortDateString(lastDayOfThisMonth);

Notice how Last Month is actually easier because you can simply move backwards a month.

var lastDayOfLastMonth = new Date(); // now
lastDayOfLastMonth.setDate(0); // last day of last month            
// set the end date first
txtEndDate.value = getShortDateString(lastDayOfLastMonth);
lastDayOfLastMonth.setDate(1);
txtStartDate.value = getShortDateString(lastDayOfLastMonth);

The only issue I had with This Year was I didn’t realize that  setMonth(int) took a zero based month: 0 = January … 11 = December.

var lastDayOfThisYear = new Date();
lastDayOfThisYear.setMonth(11); // December
lastDayOfThisYear.setDate(31);
txtEndDate.value = getShortDateString(lastDayOfThisYear);
lastDayOfThisYear.setMonth(0); // January
lastDayOfThisYear.setDate(1);
txtStartDate.value = getShortDateString(lastDayOfThisYear);

Finally, to figure out Last Year I took advantage of the setFullYear(year,month,day) function to subtract one year.

var lastDayOfLastYear = new Date();
// -1 means last year
// 11 means December and there always is a 31st of december
var thisYear = lastDayOfLastYear.getFullYear();
lastDayOfLastYear.setFullYear(thisYear - 1, 11, 31);
txtEndDate.value = getShortDateString(lastDayOfLastYear);
lastDayOfLastYear.setMonth(0); // January
lastDayOfLastYear.setDate(1); // 1st
txtStartDate.value = getShortDateString(lastDayOfLastYear);

See all of it together in the complete demo.

References:

• JavaScript Date Object
• JavaScript Date Object Full Reference

1. Building A SPGridView Control – Part 1: Introducing the SPGridView
2. Building A SPGridView Control – Part 2: Filtering

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.

Essentially, all you need to do is set a few quick properties to enable filtering on the SPGridView. (see the great tutorial on Reverse Alchemy for more information)

However, what happens if you have an apostrophe for the value in one of your filters (for example filtering on the name of O’Reilly). Eventually, you will end up with a filter of:

Name = 'O'Reilly'

If this is the case, when you attempt to filter using that value you will get the error:

Syntax error: Missing operand after 'Reilly' operator

(See the question asked by Moo on StackOverflow)

So how do you prevent the apostrophes from messing up your filter?

Where _gridDS is an ObjectDataSource (you must use an ObjectDataSource as opposed to setting the DataSource SPGridView property) and _grid is your SPGridView.

The solution is relatively simple… but what is happening behind the scenes? Actually, pretty much the same thing but without the replace. The SPGridView looks up your ObjectDataSource using the DataSourceID property. Once it has your ObjectDataSource, it then sets the property specified in FilteredDataSourcePropertyName (FilterExpression) to be the filter. Once you understand that behind the scenes, all it really is doing is setting the FilterExpression on your datasource, it is pretty easy to override the incorrect filter with a correct one.

The workaround involves setting the eventtypeindex in the SPAlert Properties. Since I designed my web part to be configurable, an admin is able to specify the following web part properties

• SPEventType WPPAlertEventType
  (Add, All, Delete, Discussion, Modify)
• SPAlertFrequency WPPAlertFrequency
  (Daily, Immediate, Weekly)
• int WPPAlertTimeHour
  (the hour of the day 0 – 23, only applies to Daily and Weekly alerts)
• int WPPAlertTimeDayOfWeek
  (the day of the week 0 – 6, only applies to Weekly alerts)
• bool WPPSendConfirmationEmail
  (whether or not to send the email saying that they were signed up for the alert)

Unfortunately, you can’t just convert WPPAlertEventType and put it in “eventtypeindex” because SPEventType’s enums were defined to have wacky binary values.

References:

• How To Create Alerts Programmatically