16.01.2013 Views

Microsoft Sharepoint Products and Technologies Resource Kit eBook

Microsoft Sharepoint Products and Technologies Resource Kit eBook

Microsoft Sharepoint Products and Technologies Resource Kit eBook

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

104 Part II: SharePoint <strong>Products</strong> <strong>and</strong> <strong>Technologies</strong> Architecture<br />

Web Part Pages<br />

Web Parts<br />

Web Part Pages in Windows SharePoint Services are designed to take disparate information<br />

<strong>and</strong> consolidate it into one location. The elements—Web Parts—that make<br />

up a Web Part Page in Windows SharePoint Services affect how the page is processed<br />

<strong>and</strong> displayed. Web Parts are grouped on the Web Part Page into containers<br />

called Web Part zones. Each of these components has an important part in the<br />

behavior of Windows SharePoint Services site pages.<br />

Physically, Web Part Pages are ASP.NET files (.aspx) that can be modified in an<br />

HTML editor, such as <strong>Microsoft</strong> Office FrontPage 2003, that works with Windows<br />

SharePoint Services. There are eight templates that come with Windows SharePoint<br />

Services that can be used to create a Web Part Page. Each of these templates contains<br />

a different set of Web Part zones to which Web Parts can be added.<br />

Web Parts are derived from ASP.NET Server Controls, but are designed so that they<br />

are more easily customized than a st<strong>and</strong>ard ASP.NET control. Unlike st<strong>and</strong>ard<br />

ASP.NET Server Controls, Web Parts remove the properties from the code of the control.<br />

The code <strong>and</strong> properties of a Web Part are separated to allow users to be able<br />

to manipulate the properties without getting into the code. The code of a Web Part<br />

resides in an assembly file that is an ASP.NET dynamic-link library (DLL), while the<br />

properties are loaded into the content database of a site.<br />

When a Web Part is installed, the assembly file is often placed in the \bin subdirectory<br />

of the virtual server that is hosting the site. The path for this directory on<br />

a default website in IIS is \inetpub\wwwroot\bin. The other location available for<br />

assembly files is the Global Assembly Cache (GAC). By default, this is the \%systemroot%\assembly<br />

directory.<br />

Files stored in the \bin directory are only partially trusted, meaning that these<br />

files cannot automatically save data to the content database or work with the Web<br />

Part object model. Saving a Web Part assembly file to the GAC not only allows the<br />

Web Part to do these things, it also makes the Web Part available to all virtual servers<br />

on a front-end Web server.<br />

Some Web Parts also include additional files, called resource files, which are<br />

needed for the Web Part to display correctly. Any included resource files are also<br />

stored locally on the site server. <strong>Resource</strong> files can range from images to language<br />

files, depending on the purpose of the Web Part. <strong>Resource</strong> files can be placed in the<br />

inetpub\wwwroot\wpresources directory, but only if the Web Part assembly file is<br />

in the \bin directory. If the assembly file is located in the GAC, the resource files<br />

must be placed in the :\program files\common files\microsoft sharepoint\web<br />

server extensions\wpresources directory. Any file that is URL addressable<br />

should be considered a resource file <strong>and</strong> placed in the appropriate<br />

\wpresources directory.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!