Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Master Advanced List Editing in SharePoint

Sometimes SharePoint's built-in editing tools aren't enough. But if you want to custmize your lists you'll need to know a good bit about how SharePoint works under the covers. This article will tell you everything you need to know to perform custom list editing for your Web parts.


advertisement
harePoint's built-in tools are good at providing a basic interface for adding and editing data, however, there are times when the included editing features aren't enough. There are applications where the SharePoint list will work, except for one small detail. For instance, you may need to ensure that one of the fields in your list matches a back-end data source. This might be accomplished by creating a drop-down that is populated from a back-end system, or perhaps it's some custom validation that ensures that the data that the user enters is in the back-end system.

Tearing open SharePoint to find a facility for these additional features is difficult. It requires an understanding of how SharePoint works overall as well as how it handles drawing a list. However, by the end of this article you'll understand the overall architecture, the details that make it work, and you'll have a framework for creating your own custom list editing solution.

One Little, Two Little, Three Little Web Parts
You know that SharePoint is built on Web parts, however, the extent to which SharePoint utilizes Web Parts internally may surprise you. Nearly every page that you see in SharePoint—from the default.aspx on every site to the forms pages at the heart of each list—is a Web Part Page.



Although the list pages don't look like it, they are Web part pages. They don't have the controls to allow the user to edit the page, but they are Web part pages nonetheless. If you would like to prove that to yourself simply add ToolPaneView=2 to the end of the query string and reload the page. You'll see that the Add Web Parts tool pane, the border around the Main Web part zone, and the title bar on the default Web part will show up.

The Web part that SharePoint uses to display and edit items in a list is the same one used to add new items to a list—that is, the ListFormWebPart. With the trick of adding ToolPaneView=2 to the end of the URL you can add or remove Web parts from any Web part page in SharePoint. Figure 1 shows the result of adding ToolPaneView=2 to the end of the query string on the edit page of an announcements list.

Figure 1. Adding the ToolPane View: The Add Web Parts toolbar shows up if you add ToolPaneView=2 to the query string.
Because you can add or remove Web parts from any page it becomes possible to swap out the SharePoint provided ListFormWebPart for your own Web part that performs a similar, but not identical, function. You can add to ListFormWebPart's basic functionality by adding enhanced validation and/or access to a database for populating drop-down boxes.

The bad news is that you can't sub-class the ListFormWebPart—making your own on the foundation that's already been laid with the existing code. You'll have to build your own replacement from the ground up. Like many classes in SharePoint the ListFormWebPart has been sealed. However, since much of what ListFormWebPart does is actually handled through JavaScript that you can still use, replicating the functionality of ListFormWebPart isn't as problematic as it may first appear.

Understanding Limitations
There are a few limitations that you must be aware of if you decide to modify the editing in SharePoint. While this technique will allow you to change how users modify data while in the Web interface, it won't stop them from editing the data in either data sheet view or in other applications via the SharePoint lists Web service. The most frequent example is the way that Excel spreadsheets remain linked to the data.

So while it's possible to change the way users edit data from within the Web interface, the technique isn't perfect. You'll have to make sure that you either remove this functionality from the list template to edit in the data sheet view or educate your users on the limitations. Generally, educating users that the data sheet view remains true to the core SharePoint functionality is acceptable. They get the enhanced editing functionality only through the Web interface.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap