Freigeben über

Web Parts in Office SharePoint Server 2007

  • Artikel

Web Parts

When adding functionality to existing and new sites, it is important to be able to decide between “use Out of the Box”, buy 3rd Party Web Parts, use Community Web Parts, or custom develop the webpart from scratch or by taking community Web Parts in house.

 

Overview

· Use and configure Out of the Box Web Parts à Realise value from existing investment.

· Buy 3rd Party SharePoint Solutions depending on support model and code access/ functionality request availability.

· Use Community Web Parts with restrictions 

· Develop your own Web Parts

 

Deciding between Third Party versus Custom Web Part development

· When deciding whether to buy a 3rd Party web part or custom develop a Web Part , weigh up following criteria:

o cost of buying the webpart

o support model available

o Web Part provider company

§ Availability (Email only; telephonic; 24 hour?; on site)

§ Location

§ Time Zone

§ Can this company understand your native language?

§ Source Code License?

§ Feature Request framework in place: Can a customer request and pay for new functionality required for the Web Part?

o Complexity of the webpart

o Do you have access to the source code? (Even if under license)

o Keep in mind future changes you may require to the webpart when buying.

 

Deciding whether to use Community Web Parts

· As a rule of thumb, the answer should always be NO until explicit permission is given for each webpart by your change control governance board.

· Community Web Parts are awesome, but pose a risk to your environment that needs to be managed.

· There are a bunch of high value, FREE Web Parts available for download from sites such as CodePlex, and SharePoint blogs. Most of them provide the source code to allow you to take the Web Part in house. 

· Don’t rule them out completely, always seek to reuse IP, rather than build complex functionality from scratch.

· Analyse performance, security, code of community webparts. Don’t simply trust that they will work.

· Test, test, test in test environment before releasing into your Production environment.

· Assess, assess, assess impact on performance in production

 

Third Party / Community developed Web Part Sources

Disclaimer:

1. This is not a comprehensive list of web parts available. It is intended to be a starting point that should be expanded and maintained as you learn about new web parts from 3rd Parties and Community Sources.

2. It is not an endorsement of any particular product over another product in the market. It merely represents my subjective experience and exposure to these products. Therefore, you should always aim to perform a diligent search for Web Parts and their competing solutions.

Sites

Mark Kruger, MVP has a fantastic list of 3rd Party Web Parts:

https://www.sharepointblogs.com/mkruger/archive/2007/06/26/free-sharepoint-web-parts-3rd-party.aspx Some of these were developed for WSS 2.0 and some for WSS 3.0. WSS 2.0 can still be used and deployed in WSS 3.0 however ensure you test and check that the functionality works in your environment.

Ian Morrish https://www.wssdemo.com/default.aspxThis is a fantastic site that has tons of demos for you to view and links to SharePoint resources on the web.

Bamboo Solutions: https://store.bamboosolutions.com/

CorasWorks: https://www.corasworks.net/Products/

CodePlex: https://www.CodePlex.Com  CodePlex is Microsoft's open source project hosting web site. Start a new project, join an existing one, or download software created by the community.

SharePointPedia:    https://www.SharePointPedia.Com This site contains links to tons of SharePoint resources, including web parts. SharePointPedia.com is a web site where people discover and share useful content about SharePoint and SharePoint related products and technologies.

 

Web Parts

Develop your own Web Parts

Web Parts in Windows SharePoint Services provide developers with a way to create user interface elements that support both customization and personalization. A site owner or a site member with the appropriate permissions can customize Web Part Pages using a browser or Microsoft Office SharePoint Designer 2007 by adding, reconfiguring, and removing Web Parts.

The term customization implies that changes are seen by all site members. Individual users can further personalize Web Part Pages by adding, reconfiguring, and removing Web Parts. The term personalization implies that these changes will be seen only by the user that made them. Developing custom Web Parts provides an easy and powerful way to extend Windows SharePoint Services sites.

Because the Windows SharePoint Services Web Part infrastructure is now built on top of the ASP.NET 2.0 Web Parts control set, you can reuse your knowledge of ASP.NET programming to create quick and robust custom Web Parts.

Following are some ways in which you can use custom Web Parts:

· Creating custom properties you can display and modify in the user interface.

· Improving performance and scalability. A compiled custom Web Part runs faster than a script.

· Implementing proprietary code without disclosing the source code.

· Securing and controlling access to content within the Web Part. Built-in Web Parts allow any users with appropriate permissions to change content and alter Web Part functionality. With a custom Web Part, you can determine the content or properties to display to users, regardless of their permissions.

· Making your Web Part connectable, allowing Web Parts to provide or access data from other connectable Web Parts.

· Interacting with the object models that are exposed in Windows SharePoint Services. For example, you can create a custom Web Part to save documents to a Windows SharePoint Services document library.

· Controlling the cache for the Web Part by using built-in cache tools. For example, you can use these tools to specify when to read, write, or invalidate the Web Part cache.

· Benefiting from a rich development environment with debugging features that are provided by tools such as Microsoft Visual Studio 2005.

· Creating a base class for other Web Parts to extend. For example, to create a collection of Web Parts with similar features and functionality, create a custom base class from which multiple Web Parts can inherit. This reduces the overall cost of developing and testing subsequent Web Parts.

· Controlling the implementation of the Web Part. For example, you can write a custom server-side Web Part that connects to a back-end database, or you can create a Web Part that is compatible with a broader range of Web browsers.

Deciding whether to create ASP.NET Web Parts versus SharePoint Web Parts

When you are creating Web Parts for Windows SharePoint Services, you have the option of creating Web Parts that inherit from System.Web.UI.WebControls.WebParts.WebPart (recommended) or the Windows SharePoint Services WebPart class.

(The Windows SharePoint Services WebPart class was available in Windows SharePoint Services 2.0, and was part of a Web Part infrastructure that was designed specifically for SharePoint sites.)

Now that Windows SharePoint Services fully supports the Microsoft ASP.NET 2.0 Web Part infrastructure, you should design Web Parts that inherit from the ASP.NET 2.0 System.Web.UI.WebControls.WebParts.WebPart base class whenever possible. Web Parts such as these are known as ASP.NET Web Parts, and can be used in Windows SharePoint Services applications whether Windows SharePoint Services is involved or not, making them highly reusable.

Note: If you are creating your Web Part specifically for a SharePoint site, and it will consume the Windows SharePoint Services object model, you can derive from the ASP.NET System.Web.UI.WebControls.WebParts.WebPart base class and add a reference to the SharePoint object model in your project.

For more information about creating ASP.NET Web Parts, see Web Parts Control Set Overview in the ASP.NET documentation.

When to Derive from the Windows SharePoint Services WebPart Class

In a very few cases, you may have to create Web Parts that support Windows SharePoint Services features that are not available in the ASP.NET Web Part infrastructure. In these cases, you can create a class that inherits from the Windows SharePoint Services WebPart base class. Web Parts such as these are known as SharePoint Web Parts and can only be used in SharePoint sites.

Note: The Windows SharePoint Services 3.0 Web Part functionality is essentially unchanged from Windows SharePoint Services 2.0.

Following is the list of features provided exclusively by the Windows SharePoint Services WebPart class:

· Cross page connections

· Connections between Web Parts that are outside of a Web Part zone

· Client-side connections (Web Part Page Services Component)

· A data caching infrastructure that allows caching to the content database

Another reason you may consider deriving from the SharePoint WebPart class is related to creating new versions of your Web Parts. If your original Web Part derived from the SharePoint WebPart class, and you want to upgrade instances of that Web Part to a new version, then the new version of the Web Part should also derive from the SharePoint WebPart class.

Comments

  • Anonymous
    July 13, 2008
    PingBack from http://www.basketballs-sports.info/better-basketball/?p=1267
  • Anonymous
    July 16, 2008
    Brian,I'm writing a web part in VB.NET (clients requirements, not mine) and derive directly from System.Web.UI.WebControls.WebParts.  Everything is working except now I need to implement caching at the application level (to store a bit of static information) to boost my simultaneous user count.  I've noticed the ASP.NET web part class doesn't appear to have built-in caching as the SharePoint web part does.I'm thinking I need to turn to System.Web.Caching.  Do I include a class in my VB Web Part project with the following signature: Public Class [Global]     Inherits System.Web.HttpApplicationthen implement Application_Start to set up the cache?  Does that even fire from within a web part housed on a SharePoint web part page?  If so, I'd set up Shared methods in this Global class to read, write, update the cache...Does this seem the correct way of going at it?Thx, Paul
  • Anonymous
    July 16, 2008
    Brian,I've figured out I was on the wrong track with my last post.  I don't need to try to access the web application via an inherited class.  I've found instead the Page object upon which my web part sits provides a reference to the existing web application cache. whew!As in: Page.Cache.Get("MySetting")Thx, Paul