SharePoint – The role of a Web Part vs using application pages

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

Web Parts are really nice server side controls that give the user the following benefits

  • Personalisation
    • 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.
  • Reusability
    • Web parts are intended to be reused on many different site pages
  • Communication
    • 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

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

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.

Conclusion

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.

5 Responses to SharePoint – The role of a Web Part vs using application pages

  1.  

    Cool article.

    Thank You

  2.  

    Thanks Brett, this helps us allot!

  3.  

    Brett this is a great article.I am new to sharepoint,I want to create a web part that displays links on the landing page based on the user’s access or security group he belongs to, for e.g if the user belongs to management security group, I will display the link which takes the user to management application/site which may not necessarily be within sharepoint. Any idea how I may accomplish this? From your article I reckon it would be a good idea to create appication page rather than web part.

  4.  

    Hi Sam,

    I presume there will be other content on the home page such as marketing, news and other summary / dashboard informatio. Home pages and landing pages typicall are dashboards.

    They way I look at this is your component is a summary of links that the user may access and should be a web part. This part can be used elsewhere to assist the user in navigating.

    So my answer your component should be a web part.

  5.  

    I have given some comments on Sam’s post on the forum post that corresponds with this comment.

    http://grounding.co.za/forums/t/690.aspx

leave your comment