An Architectural Introduction to Web Parts and ASP.NET

An Architectural Introduction to Web Parts and ASP.NET

Web Part Framework The Web Part Framework is the basis for extensibility in Windows SharePoint Services. It allows developers to write custom components that plug into the SharePoint infrastructure by encapsulating web services and enterprise data as Web Parts. Windows SharePoint Services as a whole is based heavily on .NET technologies: · ASP.NET instead of ISAPI for base page execution · CLR based server object model for programmatic access to SharePoint data · XML Web services-based access of SharePoint data from remote machines In keeping with this investment in .NET technologies, the Web Parts Framework is also based entirely on ASP.NET: · Web Part pages are ASP.NET pages. ·

Web Parts are ASP.NET custom controls. The fundamental notion in the Web Part Framework is that of a Web Part Page. A Web Part Page is essentially a scalable version of the Digital Dashboard. It is a container of Web Parts. A Web Part Page uses Windows SharePoint Services to store per-user views of the page, which enables powerful customizations on a user-by-user basis.

What Are Web Parts?
Web Parts are customizable plug and play components that empower information workers to create personalized user interfaces by simply dragging and dropping them onto a web page. Web parts allow customization at both design time and at run time. In fact, Web Parts blur the distinction between design time and run time: ·
Web page authors use FrontPage 2003 to work with Web Parts by dragging and dropping them to a Web Part Page, and then customizing them using the developer enabled properties. In this sense, Web Parts are similar to design time controls. · Web Parts also enable web page authors to use the browser as their authoring platform. Windows SharePoint Services provides a browser-based interface to design a SharePoint based site. ·

The end user can customize a Web Part Page at run time by modifying the properties of each individual web part. The page author can designate which web parts can be customized or not by grouping them into “zones” and setting the appropriate properties on the zone using FrontPage 2003. From the point of view of a developer, a web part is simply a specialized ASP.NET server control. To create a new Web Part, you create an ASP.NET custom control. However, unlike standard ASP.NET controls, which developers add to Web form pages at design time, Web Parts are intended to be added to Web Part Pages either by authors at design time, or by users at run time. Note: Developers can also use Web Parts in “regular” ASP.NET pages, but in doing so, the developer loses the advantages of integration with Windows SharePoint Services.

Web Parts and Windows SharePoint Services Web Parts rely heavily on Windows SharePoint Services to support: ·
Creation of new sites and new pages ·
Management of the user roster for a site ·
Storage of Web Part customizations, including shared and personal property settings · Administration of site backups and storage limits ·
A scalable architecture that can handle thousands of sites and millions of users ·
Assignment of users to customizable site groups In turn, SharePoint Products and Technologies rely on Web Parts to provide configurable and extensible user interfaces.

Composition of a Web Part A Web Part is composed of the following entities: · The Web Part description file (.dwp) is a portable container of default and personalized property values for the Web Part. · The Web Part assembly file (.dll) contains the logic and code for the Web Part, and is installed on the server running Windows SharePoint Services. · Resource files that support the Web Part; these are also stored on the server. ·

Tables in the Windows SharePoint Services database are used to store current values of the Web Part properties. Windows SharePoint Services has been designed from the ground-up to be a powerful collaborative platform. It is possible and indeed commonplace for your web site to contain multiple instances of the same Web Part. Each instance would conceivably have a different set of properties. Regardless of the number of instances of the Web Part, there is only one Web Part assembly file. Any instance-specific customizations are stored in the .dwp file and there exist as many .dwp files for a Web Part as there are instances of that part.