On a recent client engagement, we had a somewhat common requirement that we had solved several times before. It was part of a multi-month complete extranet solution with extensive branding and user interface design/layout. The site's overall feel from a UI and design perspective was intuitive, sleek and quite honestly, beautiful.

Although the particular requirement wasn't overly complex or new to our team, we decided to solve this using an approach we had never tried before to maintain the sleek look and feel of the site. I will not get into every detail of exactly how this was accomplished, but I will step through the client requirement, our analysis, the approach we used to solve this problem and the final results.

The Client Requirement:

• Display a "success" or "failure" confirmation after a particular item in a list was edited, then refresh the list to show the newly added/updated values.

Our Analysis:

• On the surface, this seemed like a fairly simple problem to solve, but in order to do it right, some additional work would need to be done.
• The easiest, but not necessarily the sexiest way to solve this problem would be to show a JavaScript alert() after saving the dialog. But we felt this was clunky and simply not good enough for the client.
• As the title of this post implies, the approach we took was to leverage the UI.Status framework that was released with SharePoint 2010. This approach would allow us to leverage out-of-the-box functionality and have a nice, clean and integrated status confirmation.

Our Approach:

• By default, when you edit list item or document properties, it opens these properties in a SharePoint dialog box (SP.UI.Dialog).
• The problem with this is that you have no easy way to control what I'll call the dialog instantiation process. In other words, this is all handle by the default list view. When you edit, it opens the dialog, and when you save the dialog, it simply closes the dialog and refreshes the page.
• What we needed was a way to control the opening of the dialog. In doing so, we would be able to fully control the dialog creation and leverage a callback method that is a part of the dialog framework: dialogReturnValueCallback
• This method allows you to specify another JavaScript function that will be called after the dialog closes. You can also and you can also capture which button was clicked in the dialog by using the SP.UI.DialogResult enumeration.
• Once we were in control of the dialog, we were home free…or were we?
• Next, we needed to code our JavaScript callback function. This method would simply look at the SP.UI.DialogResult and if it was OK, then show a status message in green, otherwise, show a status message in red. Simple enough. However…
• If you read the requirement, the client needed the list to refresh to show the added/updated values. If we close the dialog and refresh the page using the out-of-the-box RefreshOnDialogClose() or SP.UI.ModalDialog.RefreshPage() then we lose the context of the dialog that we just closed. If we immediately show the status and then refresh the page, the status immediately goes away since the client context is reset. There had to be a better way…
• As with most problems, there were probably a few ways to approach this one, but ultimately we decided to simply refresh the page by simply reloading it, but we appended our own querystring parameter so that we would know that we are refreshing a page that previously had a successful save. We chose a unique querystring parameter that SharePoint did not use, and simply reloaded the page adding this parameter to the end of the URL.
• The last piece of the puzzle was to show the status based on this querystring parameter. We added a JavaScript function called showStatus()which looked at the querystring and if it denoted success, then show a green status message. To show the status, we leveraged the SP.UI.Status framework.

The Results:

Editing and item and changing it from Weekly to Daily:

After page refresh, the page shows the newly updated value and the green status bar for the user:

To find out more about this blog post or C5 Insight, please fill out our Contact form.