An Architectural Introduction to Web Parts and ASP.NET

bubblemessengerΑσφάλεια

5 Νοε 2013 (πριν από 4 χρόνια και 1 μήνα)

217 εμφανίσεις




An Architectural Introduction to Web
Parts and ASP.NET

A Microsoft
®

Office
FrontPage
®

2003 White

P
aper

This
white paper

discusses the technology behind Web Parts. The paper begins by discussing
ASP.NET and describes the fundamentals of a Web Forms page
. This discussion segues into
a high
-
level overview of building a Web Part using Visual Studio.NET 2003 including mention
of the interfaces that a Web Part needs to expose in order to be connectable to other Web
Parts.

Note:
The instructions, screenshots,
and behavior discussed in this white

paper are based
on Microsoft Internet Explorer version 5.5 or above. The user experience with prior
versions of Microsoft Internet Explorer and with other browsers is going to be different


in
general, the same level o
f features may not be available.

The examples in this white paper assume that Windows SharePoint Services is installed
on a server named
myserver1024
. This server also has Microsoft SQL Server with the
Northwind

sample database installed on it

Requires a
familiarity with the basics of C# language and the .NET framework.

Published:
Novem
ber 2003

For the latest information, please see
http://www.microsoft.com/url/


1





2



Contents
Introduction

................................
................................
................................
................................
.
1

Web Part Framework

................................
................................
................................
..................
2

What Are Web Parts?

................................
................................
................................
............
2

Web Parts and Windows SharePoint Services

................................
................................
.....
2

Composition of a Web Part

................................
................................
................................
....
3

Br
ief Overview of ASP.NET

................................
................................
................................
........
4

ASP.NET Web Applications

................................
................................
................................
..
4

Web Forms Pages and Server Controls

................................
................................
................
4

ASP.NET Custom Controls
................................
................................
................................
....
7

Creating Custom Web Par
ts

................................
................................
................................
.....
11

Installing the Web Part Library Template

................................
................................
............
11

Creating and Deploying Web Part

................................
................................
.......................
12

Example: A Sample Web Part

................................
................................
.............................
12

Creating a Web Part Descr
iption File (dwp)

................................
................................
........
14

Deploying the Web Part

................................
................................
................................
.......
15

Deploying in a Windows SharePoint Services Library

................................
....................
15

Importing the Web Part into a Specific Page

................................
................................
..
16

Using the Web Part in FrontPage 2003

................................
................................
...............
16

Conclusion (Style = Heading 1)
................................
................................
................................
.
21

References

................................
................................
................................
................................
21



1

An Architectural Introduction to Web Parts and ASP.NET


1


Introduction

The Web Part Framework in Windows SharePoint Services prov
ides a powerful and easy to
use platform for developing data driven web sites. Microsoft FrontPage 2003 integrates closely
with Windows SharePoint Services and is the easiest and the most powerful web site design
tool that enables creation of
a

new categor
y of collaborative, scalable, data driven web sites.

The Web Part Framework in Windows SharePoint Services is used by
three
categories of
users
:



End users

personalize

a Web Part Page to simplify and focus on the information that is
most relevant to them.

They do this by customizing web part properties



Web Page Authors

use Web Parts to build
custom solutions

based on Windows
SharePoint

Services.



.NET developers

extend

Windows
SharePoint

Services by encapsulating web services
and enterprise data as Web Part
s.

The goal of this document is to enable
Web Page Authors

to make more efficient use of the
Web Part Framework by illustrating how
.NET developers
write Web Parts.


2

An Architectural Introduction to Web Parts and ASP.NET


2


Web Part Framework

The Web Part Framework is the basis for extensibility in Windows ShareP
oint 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 Di
gital 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 pl
ay 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 d
esign 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 cont
rols.



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 modify
ing 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 devel
oper, 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.

We
b Parts and Windows SharePoint Services

Web Parts rely heavily on Windows
SharePoint

Services to support:


3

An Architectural Introduction to Web Parts and ASP.NET


3




Creation of new sites and new pages



Management of the user roster for a site



Storage of Web Part customizations, including shared and personal prop
erty 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 P
arts 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 Pa
rt.



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
Sha
rePoint

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 cont
ain
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 stor
ed in the .dwp file

and

there exist as many
.dwp files for a Web Part as there are instances of that part.


4

An Architectural Introduction to Web Parts and ASP.NET


4


Brief Overview of ASP.NET

As we noted in the Introduction, the Web Part infrastructure is based on .NET technologies,
specifically ASP.NET. Web Par
ts themselves are
specialized
ASP.NET custom controls

and

they reside on a Web Part Page, which is
a specialized
ASP.NET web forms page.

For readers that may not be familiar with these technologies, this section gives a
very brief

overview the main concep
ts. The reader should refer to many excellent books and articles on
this topic.

ASP.NET Web
Applications

ASP.NET is part of the .NET Framework and is the core technology for developing web
applications and XML Web Services.
ASP.NET pages
run

on the server
and generate markup
such as HTML, WML, or XML that is sent to a desktop or mobile browser. ASP.NET pages
use a compiled, event
-
driven programming model that improves performance and enables
separating
the application logic and user interface. ASP.NET pages

and ASP.NET XML Web
services files contain server
-
side logic (as opposed to client
-
side logic) written in Visual Basic
.NET, C# .NET, or any .NET
-
compatible language. Web applications and XML Web services
take advantage of the features of the common langu
age runtime, such as type safety,
inheritance, language interoperability, versioning, and integrated security.

An ASP.NET web application is defined as
all files, pages, handlers, modules, and executable
code that
you
can
invoke
or run in the scope of a gi
ven virtual directory (and its subdirectories)
on
an IIS server
.
Typical ASP.NET applications consist of the following:



One or more

web forms pages


which are text files with an
.aspx

extension. These pages
typically
consist
of HTML markup which declares
the controls on the page and specifies
their formatting and layout attributes.



One or more code files;
you can
developed in
develop
code C#, Visual Basic, J#, Jscript,
etc. The code files contain the web application’s logic, including control event handli
ng,
postback handling, etc. The code files are tightly bound to the aspx files and are referred
to as “code behind”.



A Global.asx file to deal with session and application startup and clean
-
up logic. This file is
optional.



A Web.config file used to store
configuration settings. This file is optional, and is new for
ASP.NET

Web Forms Pages and Server Controls

Let’s look at a web forms page in more detail. In doing so, we will gain an understanding of
ASP.NET server controls and code behind files.

Note
This
section provides a walkthrough for building an ASP.NET web application so that the
reader can gain an understanding of the platform technologies
that

form the basis for web part
pages. However, it is not possible to run arbitrary ASP.NET code within a web
part page;
specifically, you cannot insert the code presented in this section inside a web part page.

Web forms are ASP.NET pages which use ASP.NET server controls. Server controls are a set
of built
-
in controls which are similar to Microsoft Visual Basic

controls


essentially,
prewritten

pieces of code which
you
can
drag and drop
into your application. Just like Visual Basic
controls, ASP.NET server controls are event driven; the
developer’s
task is to write code that

5

An Architectural Introduction to Web Parts and ASP.NET


5


handles events raised by the control
s. This code appears in the code
-
behind file of the
corresponding aspx file.

ASP.NET provides
two
sets of built
-
in server controls:



HTML controls
, which provide a 1
-
1 mapping to HTML elements



Web controls
, which provide prepackaged UI functionality such a
s text boxes, data grids,
labels, etc. In addition, a class of Web controls, called Validation controls, are used to
validate user input on a form (usually avoiding a
round
-
trip

to the server)

Let us now examine a sample web application. Below is a screens
hot of the application:


The user types his name into the text box and clicks on the button labeled
ClickMe
. The
application displays the text: “Hello World! This is <name>”.

Apart from the configuration files (global.asx, web.config), this application c
onsists of 2 main
files: Webform1.aspx


which is the web forms file, and WebForm1.aspx.cs, which is the code
behind file.

Shown below is the WebForm1.aspx

file
:

File WebForm1.aspx


1.

<%@ Page language="c#" Codebehind="WebForm1.aspx.cs"




AutoEventWire
up="false" Inherits="TestWebApp.WebForm1" %>

2.

<!DOCTYPE HTML PUBLIC "
-
//W3C//DTD HTML 4.0 Transitional//EN" >

3.

<HTML>

4.

<HEAD>

5.


<title>WebForm1</title>

6.



<meta name="GENERATOR" Content="Microsoft Visual Studio .NET







7.1">


6

An Architectural Introduction to Web Parts and ASP.NET


6


7.



<meta name="
CODE_LANGUAGE" Content="C#">

8.



<meta name="vs_defaultClientScript" content="JavaScript">

9.



<meta name="vs_targetSchema"






content="http://schemas.microsoft.com/intellisense/ie5">

10.

</HEAD>

11.

<body MS_POSITIONING="GridLayout">

12.



<form id="
Form1" method="post" runat="server">

13.




<asp:TextBox id="TextBox1" style="Z
-
INDEX: 101; LEFT: 192px;








POSITION: absolute; TOP: 72px" runat="server">

14.




</asp:TextBox>

15.




<asp:Label id="Label1" style="Z
-
INDEX: 102; LEFT: 128px;






POSIT
ION: absolute; TOP: 72px" runat="server">

16.




Name

17.




</asp:Label>

18.




<asp:Button id="Button1" style="Z
-
INDEX: 103; LEFT: 224px;







POSITION: absolute; TOP: 120px" runat="server"







Text="ClickMe">

19.




</asp:Button>

20.




<asp:Label i
d="Label2" style="Z
-
INDEX: 104; LEFT: 120px;








POSITION: absolute; TOP: 184px" runat="server"








Width="272px">

21.




</asp:Label>

22.



</form>

23.


</body>

24.

</HTML>


This form is strictly markup and no code. All the code required for proce
ssing the form
appears in a separate file, called the “code
-
behind” file. This is one of the major innovations in
ASP.NET; it separates the presentation from the logic, thus solving one of the major problems
with ASP


ASP code was hard to maintain because

it was interspersed with HTML markup.



Line 1 identifies the code behind file to be webform1.aspx.cs. With this directive, the
framework knows where to look for when it needs event handlers to process the aspx file.



Line 12 begins the <form> tag, but with

the runat attribute set to “server”.



Lines 13, 15, 18, and 20 declare the Web controls used on this page. They are,
respectively, a text box, a label, a button, and another label.

For each control, its id is declared, as are some style and layout paramet
ers.


Shown below is the Code
-
Behind file for this form:

File: WebForm1.aspx.cs


1.

using System;

2.

using System.Collections;

3.

using System.ComponentModel;

4.

using System.Data;

5.

using System.Drawing;

6.

using System.Web;

7.

using System.Web.SessionS
tate;

8.

using System.Web.UI;

9.

using System.Web.UI.WebControls;

10.

using

System.Web.UI.HtmlControls;


11.

namespace TestWebApp

12.

{

13.


public class WebForm1 : System.Web.UI.Page

14.


{


7

An Architectural Introduction to Web Parts and ASP.NET


7


15.



protected System.Web.UI.WebControls.TextBox TextBox1;

16.



protected System.Web.UI.WebControls.Label Label1;

17.



protected System.Web.UI.WebControls.Button Button1;

18.



protected System.Web.UI.WebControls.Label Label2;



19.



private void Page_Load(object sender, System.EventArgs e)

20.



{

21.




// Put use
r code to initialize the page here

22.



}


23.



override protected void OnInit(EventArgs e)

24.



{

25.




InitializeComponent();

26.




base.OnInit(e);

27.



}




28.



private void InitializeComponent()

29.



{

30.




this.Button1.Click += new

31.





System.EventHandler(this.Button1_Click);

32.




this.Load += new System.EventHandler(this.Page_Load);

33.



}


34.



private void Button1_Click(object sender, System.EventArgs e)

35.



{

36.




string Temp;

37.




Temp = "Hello World!" + "This is " +
TextBox1.Text;

38.




Label2.Text = Temp;

39.



}

40.


}

41.

}


The form is represented by the class WebForm1, which is derived from the Page class in the
System.Web.UI namespace. The “Inherits” of the @Page directive (in line 1 of
WebForm1.aspx file) esta
blishes the binding between WebFrom1 class and the aspx page.



Lines 15



18
declare
s

the controls used in the form.

Note that from the perspective of code, these server controls are simply C# classes; these
classes appear in the System.Web.UI.WebControls
namespace.



Line
s 28


33 declares

the
WebForms1::InitializeComponent method
to
add a new event
handler for handling “click” events on Button1.



Line 33 adds another event handler for the Load event for this page.



Lines 34


39 declares the
Button1_Click() m
ethod
that
contains the
real logic in our web
application. This method builds the output string by taking the text from TextBox1
in
line 38
and setting this string to be the text of Label2. Since Button1_Click() method has been
designated as the event handl
er for the “click” event on Button1 in line 32, this code gets
invoked when the user clicks the button.

ASP.NET Custom Controls

The ASP.NET server control infrastructure essentially provides a code
-
reuse mechanism. It
enables the writing of
reusable

UI ent
ities which
you
can
incorporate
in a page. At runtime, the
control provides ASP.NET with HTML describing its appearance.

ASP.NET ships with a rich library of server controls. These controls address the needs of
many common web design tasks. Rich as the co
ntrol library is, there are still cases where a

8

An Architectural Introduction to Web Parts and ASP.NET


8


web developer is unable to find a control that precisely suits her purposes. It is desirable
therefore, there be a way to create custom,
reusable

UI objects that
developers
can
use
in
Web Forms.

To address s
uch situations, ASP.NET provides the ability to write your own controls. They fall
into
two
broad categories:



User Controls
provide a simple and fast method for reusing your presentation code. They
are simply HTML or ASP.NET code saved in a file with an .a
scx extension. However,
you
cannot directly call
a user control (as .aspx pages can).
You have to include them
within
an aspx page. User controls can contain almost any element that a web forms page can
contain. User controls are an evolution of Server Sid
e Includes (SSI) in ASP.



Custom Controls
are .NET components which
can produce
HTML to render themselves
in Web Forms.

This section will focus on the Custom Controls. This is because a Web Part is
an

ASP.NET
custom control.

An ASP.NET server control is a
class that derives directly or indirectly from
System.Web.UI.Control
. The following two classes are the base classes for ASP.NET server
controls
:




System.Web.UI.Control
:

This class

defines the properties, methods, and events common
to all ASP.NET server co
ntrols.
It

does not have any user interface (UI) specific features.



System.Web.UI.WebControls.WebContro
l
:

This

class derives from
Control

and provides
additional properties and methods for UI functionality

(such as ForeColor, BackColor,
Font, BorderStyle,

etc). In fact, most of the built in ASP.Net server controls derive from
this class.

Shown below is the code for a simple ASP.NET custom control.


1.

using System;

2.

using System.Web.UI;

3.

using System.Web.UI.WebControls;

4.

using System.ComponentModel;


5.

namespace MyCustomControls

6.

{

7.


[DefaultProperty("Greeting"),

ToolboxData("<{0}:ComputerName




runat=server></{0}:ComputerName>")]

8.


public class ComputerName : System.Web.UI.WebControls.WebControl

9.


{

10.



private string _Greeting;

11.



[B
indable(true),

Category("Appearance"),

DefaultValue("")]

12.



public string Greeting

13.



{

14.




get

15.




{

16.





return _Greeting;

17.




}

18.




set

19.




{

20.





_Greeting = value;

21.




}

22.



}

23.



protected override void Render(HtmlTe
xtWriter output)

24.



{

25.




output.Write("<font> "+ this.Greeting + "<br>" +


9

An Architectural Introduction to Web Parts and ASP.NET


9












"The name of this server is " +











System.Windows.Forms.SystemInformation.ComputerName
+











"</font>");


26.



}

27.


}

28.

}


The name of the contr
ol is “ComputerName”; this control has one property, called Greeting.
The control gets the name of the server and appends it to the Greeting, and produces HTML
to display this text. For example, if the server name is “MyServer” and Greeting is set to the
s
tring “Hello”, then it produces the text: “Hello. The name of this server is MyServer”



Line 5 declares the namespace, “MyCustomControls”. Every control (indeed, every .NET
component) belongs to a namespace.



Line 7 defines the design
-
time and run
-
time metad
ata
for the control,
required for (among
other things) displaying the control at design time, data binding,
displaying property
sheets, etc.



Line 8 declares the class named “ComputerName” for our control. A custom control is
implemented as a class. This cl
ass is typically derived from the WebControl class
provided by the framework.



Line 11 defines the properties for the control. At design time, the property sheet editor in
Visual Studio.net 2003 requires metadata for the property, such as its category, defa
ult
value, etc.



Lines 12


22 define the accessors for the Greeting property of our control.



Lines 23


26 declares the Render method (which is an overridden method of the
WebControl class) used to produce HTML.



Line 25 uses an HtmlTextWriter object called

“output” to produce HTML tags. This method
takes the “Greeting” property and concatenates it with the ComputerName property of the
SystemInformation class and produces this string, along with some HTML tags.

Below is an aspx page that uses this control; s
ince this control doesn’t expose any events,
there is no need for writing event handlers in the code
-
behind file.

1.

<%@ Page language="c#" Codebehind="WebForm1.aspx.cs"



AutoEventWireup="false" Inherits="TestWebApp.WebForm1" %>

2.

<%@ Register TagPrefix
="cc1" Namespace="MyCustomControls"



Assembly="MyCustomControls" %>

3.

<!DOCTYPE HTML PUBLIC "
-
//W3C//DTD HTML 4.0 Transitional//EN" >

4.

<HTML>

5.


<HEAD>

6.



<title>WebForm1</title>

7.



<meta content="Microsoft Visual Studio .NET 7.1"








name="G
ENERATOR">

8.



<meta content="C#" name="CODE_LANGUAGE">

9.



<meta content="JavaScript" name="vs_defaultClientScript">

10.


<meta content="http://schemas.microsoft.com/intellisense/ie5"








name="vs_targetSchema">

11.

</HEAD>

12.

<body MS_POSITIONING=
"GridLayout">

13.


<form id="Form1" method="post" runat="server">

14.




<cc1:ComputerName id="ComputerName1" style="Z
-
INDEX: 105;







LEFT: 160px; POSITION: absolute; TOP: 248px"







runat="server" Height="22px" Greeting="Welcome">

15.




</cc1:Compu
terName></form>


10

An Architectural Introduction to Web Parts and ASP.NET


10


16.

</body>

17.

</HTML>




Line 2 uses the @Register directive. This contains the namespace and assembly name
for the custom control. It uses the TagPrefix attribute

to prevent name collisions. For
instance, if somebody else creates a control

whose name is also “ComputerName”, then
these two controls are distinguished by the different tag prefixes (such as cc1 and cc2).



Line 14 contains the markup for

inserting the control into the page. The syntax and
semantics of this markup is

the same for
a custom control and a built
-
in control (see the
previous section for details).

When
you run
this page with the Greeting property set to “Welcome”, the output looks like this:



11

An Architectural Introduction to Web Parts and ASP.NET


11


Creating Custom Web Parts

As mentioned before in this document, Web Parts are
ASP.NET custom controls
.

Microsoft
Visual Studio.net 2003 is an excellent environment for building and debugging ASP.NET
custom controls
. Developers can
use
it
for building Web Parts as well.

There are two project templates you can use when building a Web

Part using Microsoft Visual
Studio.net 2003:



Use the
Web Control Library
project: This project template comes with Microsoft Visual
Studio.net 2003
which developers can use
for building any ASP.NET controls, including
Web Parts.



Use the
Web Part Library
p
roject: This project template is available as a free download
from Microsoft

that
is optimized for building Web Parts.

In the rest of this section, we will use the Web Part Library project template. There are several
advantages to using the Web Part Librar
y template:



A
utomatically adds a reference to the Microsoft.SharePoint.dll file, which is the assembly
that contains the set of classes required to build Web Parts.



Creates a Web Part class file
.



Creates a Web Part description (.dwp) file
.



Creates a Web Pa
rt manifest file, which is an XML file containing metadata used by
stsadm.exe during the deployment of Web Parts
.



Adds n
ew instances of the above files to the project by a simple right click; you can
also
add consumer and provider Web Part files and Tool P
art files to the project.

Note
:

each of the above should be manually accomplished when using the Web Control
Library project.

Installing the Web Part Library Template

The Web Part Library template is available for download at
http://microsoft.com/downloads/details.aspx?FamilyId=14D5D92F
-
C3A6
-
407C
-
AAD7
-
B8C41A4991BE&displaylang=en
.

To add the Web Part Library template to your Microsoft V
isual Studio.net 2003 installation,
follow these steps:

1.

Download the Web Part Library templates and run the executable
.

2.

The Setup Wizard starts. Click
Next

to install the package.

3.

Select the programming languages for which you want to install the template
s and
then click
Next
.

4.

In the text box provided, type the location of the Windows
SharePoint

Services
assembly in the file system and click
Next
.

5.

The Confirm Installation page appears. Click
Next

to continue.

6.

The Installation Complete page appears. Clic
k Close to close the Setup Wizard.


12

An Architectural Introduction to Web Parts and ASP.NET


12


Creating and Deploying
a
Web Part

To create a basic Web Part, follow these steps
:

1.

Create a new project in Microsoft Visual Studio.net 2003 based on the Web Part
Library template.

2.

Write code for the Web Part.

3.

Strongly na
me the Web Part
.

4.

Create a Web Part description file (dwp)
.

5.

Copy the Web Part assembly and the dwp file into the web application directory on the
machine running Windows SharePoint Services
.

6.

Identify the Web Part as a safe control
.

7.

Import the Web Part into
a Web Part Page or put the Web Part into the virtual server
library.

The details of each of these steps are beyond the scope of this paper; we refer the reader to
the following
white papers
:



“A Developer’s Introduction To Web Parts”



“Packaging and Deplo
ying Web Parts for Windows SharePoint Services”

Both are available for download at
http://msdn.microsoft.com/library/default.asp?url=/downloads/list/
SharePoint
.asp
.

In this paper, we will examine the sample code for a simple Web Part and look at a dwp file
that will accompany it.

Example: A Sample Web Part

The following code illustrates a simple Web Part which has a text box and a button; when you
click on th
e button, the string in the text box is appended to the title of the Web Part.

1.

using

System;

2.

using

System.ComponentModel;

3.

using

System.Web.UI;

4.

using

System.Web.UI.WebControls;

5.

using

System.Xml.Serialization;

6.

using

Microsoft.SharePoint;

7.

using

Microsoft.Sha
rePoint.Utilities;

8.

using

Microsoft.SharePoint.WebPartPages;

9.

using

System.Web.UI.HtmlControls;

10.

using

System.Runtime.InteropServices;


11.

namespace

WebPartLibrary1

12.

{

13.


[DefaultProperty("Text"),



ToolboxData("<{0}:WebPart1 runat=server></{0}:WebPart1>"),



XmlRo
ot(Namespace="WebPartLibrary1")]

14.


public

class

WebPart1 :



Microsoft.SharePoint.WebPartPages.WebPart

15.


{

16.



private

const

string

defaultText = "New Web Part";

17.



private

string

text=defaultText;


18.



// declare HTML controls used by this web part

19.



HtmlButton

_myButton;

20.



HtmlInputText _myTextBox;


13

An Architectural Introduction to Web Parts and ASP.NET


13



21.



// Event handler for _myButton control; it gets the string in




//

the text box
&
appends it
to the custom property "Text"
&





//
sets this as the title of the web part

22.



public

void

_myButton_Click (
object

se
nder, EventArgs e)

23.



{

24.




this
.Title = _myTextBox.Value + "'s " +
this
.Text;

25.



}


26.



[Browsable(
true
),Category("Miscellaneous"),




DefaultValue(defaultText),




WebPartStorage(Storage.Personal),




FriendlyName("Text"),Description("Text Property")]

27.



publi
c

string

Text

28.



{

29.




get

30.




{

31.





return

text;

32.




}

33.




set

34.




{

35.





text =
value
;

36.




}

37.



}


38.



// override Web.UI.Controls.CreateChildControls method

39.



protected

override

void

CreateChildControls()

40.



{

41.




// create _myButton control and add event handler

42.




_myButton =
new

HtmlButton();

43.




_myButton.InnerText = "Add your Name to title";

44.




_myButton.ServerClick +=
new

EventHandler(_myButton_Click);

45.




Controls.Add(_myButton);

46.




_myTextBox =
new

HtmlInputText();

47.




_myTextBox.Value = "";

48.




Controls.Add(_myT
extBox);

49.



}


50.



///

Render this Web Part to the output parameter specified.

51.



protected

override

void

RenderWebPart(HtmlTextWriter output)

52.



{

53.




_myTextBox.RenderControl(output);

54.




_myButton.RenderControl(output);

55.



}

56.


}

57.

}


You may notice that this code
looks like the code shown for ASP.NET the custom control in a
previous section. This should come as no surprise because Web Parts are ASP.NET custom
controls.

However, there exist several differences.

The first is in Line 14:



The Web Part class derives
from Microsoft.SharePoint.WebPartPages.WebPart class, as
opposed to a stock ASP.NET control, which derives from one of
System.Web.UI.Control

or
System.Web.UI.WebControls.WebControl
.


14

An Architectural Introduction to Web Parts and ASP.NET


14




However, the WebPart class itself derives from System.Web.UI.Control clas
s and this is
what ties a Web Part into the entire ASP.NET control infrastructure. To the features of a
stock ASP.NET control, the Web Part class adds the following:



Creates

the title bar
,
border

etc
.,

around the control
, which users can customize by
setti
ng properties and applying themes.



H
andles interactions with the
WebPartPage

and
WebPartZone

classes to support
adding, moving, hiding, deleting, connecting, and personalizing Web Parts on a page.

This is what “plugs” a Web Part into the Windows SharePoin
t Services infrastructure.



Provides a set of common properties such as Title, Height, Width, FrameState, etc.

The second difference is in Line 51.



When rendering an ASP.NET control, you typically override the Render method of the
base class; however, the
WebPart class has sealed the Render method. Developers
should override the special
RenderWebPart

method provided by t
he WebPart class.

The rest of the code show above is straightforward ASP.NET control code:



Lines 19 and 20 create HTML text controls used in this web part (an input text and a
button control)



Lines 21

-

25 define the event handler for the button click eve
nt. This handler simply takes
the value in the text box, appends this to the value of the custom property called “Text”,
and sets this as the new title. Thus if the Text Property is “New Web Part” and the string
“Ralph” is typed in the input text box, then

the button click will set the new title of the Web
Part to “Ralph’s New Web Part”.



Lines 26

-

37 define the accessors for the Text custom property.



In lines 38

-

49, we override the
CreateChildControls

method of the base class to
initialize the controls in this Web Part. The controls are added to the collection of child
controls for this Web Part class. Also,

we add the click event handler defined in lines 21
-
25 to the
HtmlButton
’s
ServerClick

event.

Rendering the Web Part at Design Time

FrontPage 2003 provides a design time preview of Web Parts on a Web Part Page at design
time. The developer can exercise pr
ecise
control over this design time rendering
. This is done
by implementing the
IDesignTimeHtmlProvider

interface in the Web Part
. This interface has
a single method, called
GetDesignTimeHtml
, which returns the HTML string used to render
the Web Par
t. Design tools such as FrontPage 2003 which leverage Windows SharePoint
Services, check to see if this interface is implemented; if it is, then they call the
GetDesignTimeHtml

method for rendering. Otherwise, they use the default rendering for that
Web Part.

Creating a Web Part Description File (dwp)

The
Windows SharePoint Services infrastructure uses the
Web Part descript
ion file
which
contains metadata about the Web Part.

Shown below is the dwp file for the Web Part created in the previous section:

1.

<?xml version="1.0" encoding="utf
-
8"?>

2.

<WebPart xmlns="http://schemas.microsoft.com/WebPart/v2" >

3.


<Title>New Web Part</Titl
e>

4.


<Description>WebPart1.</Description>

5.


<Assembly>WebPartLibrary1, Version=1.0.0.0, Culture=Neutral,


15

An Architectural Introduction to Web Parts and ASP.NET


15






PublicKeyToken=334fd085a590fb9f</Assembly>

6.


<TypeName>WebPartLibrary1.WebPart1</TypeName>

7.

</WebPart>


As you can see, the dwp is an XML file. The ro
ot element of this file is the <WebPart>
element, and it contains, among others, the following tags:



<Title> specifies the default title of the Web Part



<Description> specifies the pop up description for the Web Part which FrontPage 2003
and the browser

d
isplays.



<Assembly> specifies the name of the assembly that contains the implementation for this
Web Part.



<TypeName> specifies the class within the assembly which implements the Web Part.
This is required because an assembly can implement more than one W
eb Part and/or
other ASP.NET controls. Notice how the value of the TypeName tag corresponds to the
namespace declaration (line 11) and class declaration (line 14) shown in the previous
section.

Note
You can export dwp files in FrontPage 2003, using
Tools/S
ave Web Part to/File…

Deploying the Web Part

You can deploy a
Web Part
in
two
different ways:



Place it
in one of the Windows SharePoint Services Web Part Libraries


the virtual server
library, site library, or the online library. This
makes
it available t
o all pages in the site.



Import it
into a specific page
. This
make
s

the Web Part available only to that page and it
will not appear in any gallery.

Deploying in a Windows SharePoint Services Library

Before deploying the Web Part into a Windows SharePoint

Services Library, you must build a
Web Part Package. A Web Part Package is
a cabinet (.cab) file that contains the following
items:



Manifest.xml



.
dwp files


Note
:
When using the Web Part Library template for Microsoft Visual Studio.net
2003
, it automat
ically creates

the manifest.xml and dwp files for you.



Web Part assemblies
: one or more .NET assemblies and
are
the result of building your
Web Part Library solution



Class resource files

contain bitmaps and other resources required for your Web Part.

The d
etails of the structure of manifest.xml, and the modalities of building a CAB file are
outside the scope of this paper. For details, please see the
white paper

entitled “Packaging
and Deploying Web Parts for Microsoft Windows SharePoint Services”

at
http://msdn.microsoft.com/library/default.asp?url=/library/en
-
us/dnspts/html/
SharePoint
_DeployingWebParts.asp
.

Once you have a CAB fil
e, you can use the stsadm.exe tool on the server running Windows
SharePoint Services to add the Web Part to the virtual server library. The typical command
line for using stsadm.exe to add a Web Part looks like below:

stsadm.exe

o addwppack

filename

path
_to_
CAB_file


16

An Architectural Introduction to Web Parts and ASP.NET


16



The stsadm.exe tool is typically available in

<drive>
:
\
Program Files
\
Common Files
\
Microsoft Shared
\
web server extensions
\
60
\
BIN

For more details on using stsadm.exe tool, see the “Packaging and Deploying Web Parts for
Microsoft Windows Share
Point Services”
white paper

referenced above.

Using the stsadm.exe tool deploys the Web Part into the virtual server library and
you can use
with
FrontPage 2003 or the Web Browser interface.
You can make any
Web Part in the virtual
server library availabl
e in the site library. For more details on managing Web Parts in these
libraries, see “
FrontPage 2003:
Working with Web Part Libraries
”.

Importing t
he Web Part into a Specific Page

You can
also
simply import a
Web Part onto a page
.

T
he process of import does not add the
Web Part to the Virtual, Site, or Online libraries; it is just available on a given page.
Before
you
can import a Web Part onto a pag
e, you must perform the following tasks on the machine
running Windows SharePoint Services:

1.

Copy the Web Part assembly to the <drive>:
\
inetpub
\
wwwroot
\
bin folder.

2.

Register the Web Part as a safe control.
Do this
by editing the web.config file, located
in
the <drive>:
\
inetpub
\
wwwroot folder. For our sample Web Part, this involves adding
the following lines under the <configuration>/<SharePoint>/<SafeControls> block:

<SafeControl Assembly="WebPartLibrary1, Version=1.0.0.0,


Culture=Neutral, PublicKeyToken=3
34fd085a590fb9f"


Namespace="WebPartLibrary1" TypeName="*" Safe="True" />

3.

Make the dwp file for the Web Part available for the users
that want
to import this Web
Part.

Assuming these steps are performed, the Web Part can be imported onto a page using
Fron
tPage 2003 using the following steps:

1.

Bring up the Web Parts task pane: View/Taskpane and select “Web Parts” from the
dropdown list of available task panes.

2.

Under Add Web Parts, click Import.

3.

Browse to or type in the location of the .dwp file for the Web P
art you want to import.

4.

Click “Upload”. The Web Part now appears on the task pane.

You
can
now drag and drop the part onto the page.

Using the Web Part in FrontPage 2003

In this section, we will assume that our sample Web Part is available in the Virtual
Server
Library of the Windows SharePoint Services installation.

Using this Web Part is no different from using any other Web Part
. To use a Web Part,

follow
these steps
:

1.

Open the site you wish to work with in FrontPage 2003. For the purposes of this
sect
ion, we will assume the site is located at the URL:
http://myserver/my
-
workgroup
.

2.

Click on
Data/Insert Web Parts

to open the
Web Parts

taskpane in FrontPage 2003.

3.

Click on
Virtual Server Gallery

to display th
e available Web Parts. You should see
the sample Web Part available there;
its

title is
New Web Part
.

Below is a screenshot of the task

pane:


17

An Architectural Introduction to Web Parts and ASP.NET


17



4.

Drag

and drop this Web Part into an appropriate zone in your web page. For the
purposes of illustration, let us
assume that we have dragged the Web Part into the
default.aspx page of a Windows SharePoint Services site created using the
Team
Site

template.

5.

Save the page and run it in the browser by typing the appropriate URL. We have used
the URL
http://myserver/default.aspx
.

6.

Locate the Web Part you just added (it should be titled “New Web Part”).

7.

Type your name in the text box, and click on
Add your Name to title

button. The title
will change to (assuming
the

name you t
yped was Murali) “Murali’s New Web Part”.

Below is a screenshot of this:


18

An Architectural Introduction to Web Parts and ASP.NET


18



Recall that this Web Part has a custom property called
Text
. Refer to the Web Part code in
“Example: A Sample Web Part”
.

Note
the following:



Line 22


25 specifies that the event h
andler for the button click event on the
Add your
Name to title

button take the value of the Text property, append it to the string typed in
the text field, and set this as the value of the title.



Lines 26


37 implements the custom property and specifies
that this property has to be
put under the category “Miscellaneous”.

To manipulate this property in FrontPage 2003, follow these steps
:

1.

In the Web Part properties dialog box, notice the new category called
Miscellaneous
.

E
xpanding this category show
s

a pro
perty called
Text

and a text box to enter the
value for it. FrontPage 2003 automatically displays a text box to enter the value of this
property because the data type of this property is string (line 27 of the code in
“Example: A Sample Web Part”)

2.

Type “F
ancy Web Part” as the new value of this property.

3.

In FrontPage 2003, right click on our example Web Part and select
Web Part
Properties

in the pop
-
up menu.

Below
is a screenshot of how this should look:


19

An Architectural Introduction to Web Parts and ASP.NET


19



4.

Click
OK
, save changes and run the page in the bro
wser by typing the appropriate
URL. We have used the URL
http://myserver/default.aspx
.

5.

Locate our example Web Part (it
title
should be “New Web Part”).

6.

Type your name in the text box, and click on
Add your Nam
e to title

button. The title
will change to (assuming that the name you typed was Murali) “Murali’s Fancy Web
Part”.

Below is a screenshot of this:


Note
By default, the custom properties you create and specify as browsable are automatically
displayed in

the default property pane, making their use transparent to the user. If the default
property pane isn't rich enough in functionality, you can create a custom user interface called a
ToolPart to manipulate your custom properties. For information on creatin
g a ToolPart, see the
http://msdn.microsoft.com/library/default.asp?url=/library/en
-

20

An Architectural Introduction to Web Parts and ASP.NET


20


u
s/spptsdk/html/CreateWPCustomProperties.asp
.


21

An Architectural Introduction to Web Parts and ASP.NET


21


Conclusion

ASP.NET is part of the .NET Framework and is the core technology for developing web
applications and XML Web Servic
es. ASP.NET is a compiled, .NET
-
based environment; you
can author applications in any .NET compatible language, including Visual Basic .NET, C#,
and JScript .NET. Additionally, the entire .NET Framework is available to any ASP.NET
application. Developers c
an easily access the benefits of these technologies, which include
the managed common language runtime environment, type safety, inheritance, and so on.
.NET developers
write Web Parts using Visual Studio.NET 2003.

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. Web Part Pages are special
ASP.NET pages which are th
e building blocks of a Windows SharePoint Services based data
driven web site. Web page authors can use Microsoft FrontPage 2003 to leverage Windows
SharePoint Services and use the Web Part Framework to easily build data driven web sites
using a library of

readily available web parts.

Microsoft FrontPage 2003 integrates closely with
Windows SharePoint Services and is the easiest and the most powerful web site design tool
that enables creation of a new category of collaborative, scalable, data driven web sit
es.


22

An Architectural Introduction to Web Parts and ASP.NET


22


References

FrontPage 2003:
Overview of Web Parts Framework


FrontPage 2003:
Working with Web Part Libraries

FrontPage 2003:
Customizing Web Parts


FrontPage 2003:
Connecting Web Parts


FrontPage 2003:
Working with Web
Part Pages


FrontPage 2003
:
Working with the Data View Web Part


Other Microsoft Resources

Microsoft

FrontPage

2003

Customization Kit Web
:

http://www.sharepointcustomization.com


Microsoft FrontPage Web site:

http://www.microsoft.com/frontpage/default.htm


Microsoft FrontPage Add
-
in
Center:
http://www.microsoft.com/frontpage/downloads/addin/default.asp

Microsoft

SharePoint Products and Technologies
:

http://www.microsoft.com/sharepoint/default.asp


SharePoint Products and Technologies Web Component Directory:

http://www.microsoft.com/sharepoint/downloads/compon
ents/default.asp



23

An Architectural Introduction to Web Parts and ASP.NET


23


The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of

the date
of publication. Because Microsoft must respond to changing market conditions, it should not be interpr
eted to be a commitment on the
part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED
, IN THIS

DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright,
no part of this
document may be reproduced, stored in, or introduced into a retrieval system, or transmitted i
n any form or by any means (electronic,
mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft C
orporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or oth
er intellectual property rights covering subject matter in
this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document
does not
give you any license to these patents, trademarks, copyrights,
or other intellectual property.

© 2001 Microsoft Corporation. All rights reserved.

The example companies, organizations, products, domain names, e
-
mail addresses, logos, people, places, and events depicted herein
are fictitious. No association with any rea
l company, organization, product, domain name, e
-
mail address, logo, person, place, or event
is intended or should be inferred.


Microsoft,

FrontPage
, and SharePoint

are either registered trademarks or trademarks of Microsoft Corporation in the United Stat
es
and/or other countries.