In the past few weeks I have been doing some consulting and giving advice to development teams starting SharePoint development. In this process I have found it a common problem that several developers misunderstand what are site pages, applications pages and web parts are used for and when to use it. At least a dozen e-mails, MSN chats and meetings in the past few weeks has prompted me to write this post.
As a developer we have many options available to us and it is difficult at first to really understand where to use what and when to use it. Hopefully through my trials and errors I will be able to share with you what I have found works best.
SharePoint opportunities as a developer
SharePoint, WSS 3.0 leverages on top of the .NET 2.0 and 3.0 frameworks using many ASP.NET features to deliver a powerful portal engine. As an ASP.NET developer there are many different approaches to develop a web site and how to go about it. The trick with SharePoint development is to know when to use what. What makes it a bit more confusing is that many ASP.NET developers are introduced features of the .NET framework that they never new existed and the combination of the two new technologies becomes quite confusing. There is however one thing in common, however or whatever approach you take, you will be generating HTML, CSS and client side scripts.
Web Parts are really nice server side controls that give the user the following benefits
- a user can move the control to different zones on the page.
- a user can customise settings of a web part allowing data to be filtered, selected or rendered by parameters
- a user can choose to put a web part on a page or not.
- Web parts are intended to be reused on many different site pages
- Web Parts can communicate with other web parts on the same page, sharing information between the controls providing a master / detail set of controls
- Summaries and information sharing
Web parts are intended to be used to display summarised and management information to users in a dashboard type page. This page should have web parts that show results, graphs, KPI’s and keep with the spirit of a SharePoint site … that is to share and make information visible and easily accessible. The primary goal is to.
The idea of a web part has been confusing to many, and often web parts are created for the wrong reasons, these include
- data capture and entry
- one-of-a-kind web part that will be placed on a site page by an administrator and will only be used once.
- front-end controls for line of business applications.
After all, a user is not going to want to choose the location on the screen to where to capture the new account details for a new customer, nor will they choose to optionally display or hide this from their screen.
Site pages are aspx pages that have web part zones in them, allowing a user administrator to choose a web part and drop it into a zone. A site page should not need to have code behind the page and most definitely should not be hard wired to interact with a specific web part. In essence it as a template for a page that contains zones. These zones will be filled with web parts. Please do not put code into your site pages or hard wire the site pages.
Application pages are for all intense purposes the same as a traditional .aspx page where you can do what ever on the page you wish. Application pages are ideal for your line of business pages and data capture pages. Your application page can also contain as much code and complexity as you like. You can choose to interact with SharePoint or do your own thing.
Application pages should be used for
- Data capture pages
- Line of business or system pages
- Configuration pages
- Pages that are a one-of-a kind page
- Pages that should not be customised by users
- Requires code behind the page
Now, another small mistake that many developers make is that they place complex logic into the .aspx page, instead get used to putting your logic into an .asxc page and then dropping this onto your page.
Create application pages for you line of business systems and implement these into your solution. Threat these application pages as you would a traditional ASP.NET web site, however you need to play by a few Windows SharePoint Services rules. Don’t use web parts for this as it is pointless and far too much work (and pain). Create links from the navigation system of SharePoint, other pages and web parts to your application pages.
Web Parts should be created to enhance the users SharePoint experience. Create web parts that summarise information from your line of business applications. The idea here is to allow users to create dashboards to quickly get the big picture of what is going on and where they should focus their attention to. Web Parts should not be created for data capture, rather create an application page.
Site Pages should be created should you not find a suitable standard SharePoint layout for your dashboard page with all the needed zones. In this situation create your own site page.