This Article shows you the creation of customizable portals and pages using the ASP.NET 2.0’s new WebParts controls.
Introduction
This Article shows you the
creation of customizable portals and pages using the ASP.NET 2.0’s new WebParts controlsPicture
an interface where you can run several applications simultaneously. As
if your computer’s screen was divided into “windows” and, in each
“window”, you had different software running, such as a spread sheet, a
document, supply control system, etc. Sounds familiar? I think
somebody’s already had this idea has at least 20 years ago.
Let
us now transport this idea to a Web environment, an Internet page.
Think about the possibility of running various applications in a single
site’s homepage or portal; the same “windows” functionality, currently
so trivial in operational systems. Picture this functionality applied
to the Web. Pictured it? It is exactly that what ASP.NET 2.0’s WebParts
do. A Web page divided into “windows”, where in each window you run the
application of your choice, with the functionalities of opening,
moving, minimizing, closing, etc.
This
is the subject that this article will approach. Here, we’ll explain
this concept and demonstrate in practical terms how to implement WebParts in ASP.NET 2.0’s applications.
WebParts Controls
This
is not a new idea, the WebParts appeared with the Windows SharePoint
Services and the SharePoint Portal Server, Microsoft products for
implementation of sites and portals.
This same idea was recently embedded in ASP.NET, with the release of the 2.0 version. It is important to emphasize that WebPart it isn’t a single control in ASP.NET, but a new way of implementing Web applications. To implement WebParts in ASP.NET, we have a great set of controls available. We can find them in Visual Studio 2005 ToolBox (Figure 1).
Figure 1. Visual Studio 2005 ToolBox WebParts ControlsFirst ExampleLet us take a look at a simple example of how to implement WebParts functionalities. Unlike a Desktop environment, where you can place applications anywhere on the screen, in a WebParts environment you determine the locations where the “applications” can run. These locations are called zones. Think of a HTML table with several cells, in which you can drag “mini-applications” throughout these spaces.
Let’s create an example to better understand this property. In Visual Studio 2005, create a new ASP.NET project. Insert a WebPartManager control in the default page. This is the control that’ll manage WebParts properties. Below WebPartManager, insert a table with two lines and two columns. In each table cell insert a WebPartZone control. Your page should look like demonstrated by Figure 2 below.
Figure 2. ASP.NET page with four zones
In
your page’s layout, in Visual Studio 2005, the zones behave as
“containers” where we can include controls inside them. Drag a calendar
control in the first zone. In zone 2 drag a Button control as well as a TextBox control. Notice that you can place more than one control in a single zone. Our example must look like that of Figure 3.
Figure 3. Controls within zones
In the default page’s Page_Load, include the code in Listing 1. The code sets WebPartManager DisplayMode property for design mode. After that, execute your project. Your page should look like the one shown in Figure 4.
Listing 1. Setting WebPartManager DisplayMode
protected void Page_Load(object sender, EventArgs e)
{
WebPartManager1.DisplayMode = WebPartManager.DesignDisplayMode;
}
Figure 4. Project with WebParts
Observe
that each control inserted in the zones “is coated” by a window
containing a title bar, a frame and a menu, shown by the small arrow in
the right hand corner. If we move the mouse over the window title (for
now, they’re all Untitled) we’ll see that the mouse’s arrow
will change its shape. This shows us that we can click and drag this
window along the zones! Make tests and move the controls along the
zones, see as the dynamics is extremely similar to that of Windows.
Check in Figure 5 how you can move WebParts from zone to zone.
Figure 5. Moving Button control from zone 2 to zone 4
WebPart properties
When
we include controls in the zones, they show up with some peculiar
characteristics. These characteristics give them a “window” style, with
a title bar, a frame and a menu. These characteristics determine a WebPart visual style and are implemented into any control that’s included in a WebPartZone.
We can modify WebParts
graphical layout applying one of the default formats contained in
Visual Studio 2005 or simply working with the control styles. To apply
a different format to the WebPart, choose the WebPartZone Auto Format option in its Tasks. See example in Figure 6.
Figure 6. Applying a format to the zone’s Webparts
Notice that we make layout change in the zone and not directly in the control. WebParts graphical characteristics that “coat” our controls will be inherited from the zones where the controls are located.
One of the most important WebPart characteristics is the menu that we find in upper right hand corner. Inside this menu we can minimize, restore and close WebPart. See Figure 7. The default options that appear are minimize and close. When we minimize a WebPart,
all its content is “concealed”, leaving only the title bar in sight,
along with the option menu. When minimized, the menu options are to
restore and to close. When restoring, WebPart returns to its original aspect. If we close a WebPart it will no longer be shown in our page.
Figure 7. WebPart Menu
WebParts Catalogue
Where does a WebPart go when we close it? And how do we recover it in our page? All the WebParts we’re working with are controls that we, ourselves, have included in the WebPartZones. All these WebParts are part of what we call page’s WebParts catalogue.
To see the WebParts that have been closed by the user, we need two more controls in our page. First we include a CatalogZone control. This control is like a WebPartZone, where we can include other controls inside it. We must then include a PageCatalogPart control inside the CatalogZone we’ve just inserted. Your page must look like the one in Figure 8.
Figure 8. CatalogZone Controls and PageCatalogPart
In the beginning of our example we included a code into the page’s Page_Load. In this code, we set our WebPartManager DisplayMode property with the constant DesignDisplayMode. In order to gain access to our Webparts catalogue, we need to change this property with the constant CatalogDisplayMode. This sets the “mode” in which we’re working with the WebParts. Page_Load must be as shown in Listing 2.
Listing 2. Defining WebPartManager DisplayMode
protected void Page_Load(object sender, EventArgs e)
{
WebPartManager1.DisplayMode = WebPartManager.CatalogDisplayMode;
}
Run your project and make a test. See in Figure 9 that the calendar is closed and does not appear in the page anymore. It appears inside Page Catalog, which is our page’s WebParts catalogue. In it the WebParts closed by the user will always be shown. To return a WebPart to the page, we must select it by checking its respective checkbox, choose the zone to which we’re going to add it and click the Add button.
Figure 9
Conclusion
As we’ve seen, the controls for WebParts implementation
are very simple to be used. In all the tests performed here, only one
code line was used, and all the implementation was made with only the
insertion of the controls to the pages. In the tests that we carry out,
only simple controls were inserted in the zones. In a real application,
we must create our “mini-applications” such as User Controls, so that they are shown in the zones and work as WebParts. We also have the possibility of creating controls that inherit from the WebPart category, which is a resource exhaustively used by those who implement WebParts in SharePoint portals, but this subject is for a next article.Regards
Santosh