Why we should ever override RaisePostBackEvent in a SharePoint Publishing Layout Page?
We sometimes run into situations where your program needs to perform SharePoint list item updates depending on the changes made by the user to fields of that publishing page.
A simple example – let’s say that you need to do server-side validation on a field, or you need to set a value of a list item column or do something before the page gets persisted through the SharePoint data access later. In our case, we had to fire code before the save event occurs on the current time and we had to add some data in other (hidden) fields, which we read later.
In simple words, this blog post is a walkthrough about capturing the RaisePostBackEvent code-behind method on publishing pages and performing actions before the save event occurs.
For this purpose I have prepared a simple example in a bundled ZIP file. I will try to describe how the SharePoint publishing page list item can be programmatically updated by using the RaisePostBackEvent when the save page event occurs.
I have split my example into two phases. The first phase explains how to create a simple (custom) publishing page layout so if you are familiar with this you can skip it and continue with the second phase where the RaisePosBackEvent comes into play.
I am using SharePoint Server 2010 with Visual Studio 2012 installed on the server.
Phase 1. Creating a SharePoint solution and custom page layout.
- Open the Visual Studio and create SharePoint 2010 Empty Project
- Specify the site on your local SharePoint server that you want to use for debugging. I am using a Publishing Site (Out of the box).
- Once the project is created add an empty module that will be used to hold our custom page layout.
- Rename the module and the feature so the project looks better, I have renamed mine:
- Now for the creation of our custom page layout I will use one of the existing ones under my Publishing Site -> Site Settings ->; Master Pages and Page Layouts.
- You can navigate to there and download one of the existing. I downloaded ArticleLeft.aspx. (/_catalogs/masterpage)
- After the page layout is downloaded you can add it to your MyPageLayouts module and rename it to MyCustomLayout.aspx for example. We are doing this to reuse the ASPX of the page layout and not have to create our own.
- Delete the Sample.txt from the module since it is not needed. VS puts that crap in there.
- Update the Elements.xml so it would look like:
10. Add the MyPageLayouts module to the MyCustomFeature
11. Run/Start the solution to verify that the newly created MycustomLayout.apsx works as expected.
12. Go to the Publishing Site and edit the dafault.aspx, in the Ribbon go on the Page Layout button and verify that the MyCustomLayout.aspx is there.
14. Change the page layout to our custom so we can use it in the next phase or create one new publishing page in the “Pages” Document Library and apply the custom layout.
Phase 2. Using the RaisePostBakcEvent method to programmatically update list item field in the “Pages” Document Library when publishing page save event occurs
If you are not familiar with the Page.RaisePostBackEvent, one very good article with nice illustration can be found on this link: http://msdn.microsoft.com/en-us/library/ms178472(v=vs.100).aspx.
As part of the ASP.NET Page Life Cycle the RaisePostBackEvent is called in the PublishingLayoutPage (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.publishing.publishinglayoutpage.aspx) as well.
Back to the solution:
- Create a new empty Class.cs and name it PublishingLayoutEx.cs
- The new class will inherit the PublishingLayoutPage and for that reason references to Microsoft.SharePoint and Microsoft.SharePoint.Publishing should be added to the project.
- Also references (using) to Microsoft.SharePoint and Microsoft.SharePoint.Publishing should be added in the newly created class as well.
- Also reference to System.Web needs to be added to the solution because the RaisePostBackEvent method resides in System.Web.UI.Page(http://msdn.microsoft.com/EN-US/library/dfbt9et1) and the compiler would not recognize it if System.Web is not referenced.
- The complete references on the image below:
Your PublishingLayoutPageEx class should look like:
6. Go to your page layout “MyCustomPageLayout.aspx” and replace the page directive
…so the publishing page inherits your newly created class.
7. Add the RaisePostBackEvent to the class:
8. Now we can start to listen for eventArguments raised by different events (to be exact, the method is overridden).
9. Start the solution, go to the site and change the default.aspx page layout to match our custom MyCustomLayout.aspx or just create a new publishing page and apply the layout.
10. Use the edit button on the page to enter in edit mode.
If you have the debugger on, you can observe the eventArgument of the RaisePostBackEvent. It is “edit”
11. Another experiment would be to hit the SaveAndClose button and observe the eventArgument
12. And you can play around with other ribbon buttons like CheckIn, Publish etc, but that is the pay to capture them.
13. Now, new functionality can be easily added when save event is risen.
This is pretty much all of it: placing code for adding DateTime.Now in the “Comments” field if the eventArgument is “PageStateGroupSaveAndStop”. We do this before the RaisePostBackEvent then the normal save handler should update the list item with the changes made by the user. Notice we do not call the Update method on the list item, that is done internally by SharePoint
Here are some useful links with PageStateCommands and PageStateStrings that can be risen as eventArgument in the RaisePostBackEvent method.
I have not tested all of them, some may not be appropriate.
Bare in mind these are not all of the page states of the Ribbon that can be passed as eventArgumens in the RaisePostBackEvent method. I have discovered a few others during my development that are not listed in MSDN (like ChangePageLayoutEvent, PageStateGroupSaveSplit, PageStateGroupOpenMenuSave, PageStateGroupQuerySaveMenu) and maybe there are more.