ASP.NET 2.0 customizable Portals and Pages

WebParts

ASP.NET 2.0 customizable Portals and Pages

Rodrigo Sendin Silva

This article analyzes	This article uses the following technologies:
·         The creation of customizable portals and pages using the ASP.NET 2.0’s new WebParts controls; ·         WebParts catalogs and menus using zones.	.NET Framework 2.0, ASP.NET 2.0, Visual Studio 2005, WebParts.

 

Picture 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 Controls

First Example

Let 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.

 

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.

 

Figura 9. Acessando o catálogo de WebParts da página

Editing a WebPart during running

A property we can observe is that all WebParts are named Untitled. This title cannot be modified in the control properties. So, what do we do to modify it? In the same way as WebPart heading, we have a set of properties that can be modified in our project’s running mode. In order to do this, we will again need to include two more controls in our page. First, we include the EditorZone control, and after that we include, inside EditorZone, the edition control that we need.

Notice that we have some controls that end with the name EditorPart. All of these controls are meant to edit our page’s WebParts characteristics. For our example we’ll include a AppearanceEditorPart control inside the EditorZone control. Your page should look like the one in Figure 10.

 

Figure 10. Including WebParts characteristics editing controls

Notice that in the AppearanceEditorPart control are already displayed the appearance properties that we can modify in WebParts, including Title property. To finish, we must once again change WebPartManager DisplayMode to the EditDisplayMode constant. As we’ve explained previously, DisplayMode defines the “mode” in which we’re working with WebParts. In order to edit its properties, DisplayMode needs to be modified to EditDisplayMode. See what your event Page_Load must look like in Listing 3.

 

 

Listing 3. Setting WebPartManager DisplayMode

protected void Page_Load(object sender, EventArgs e)

{

    WebPartManager1.DisplayMode = WebPartManager.EditDisplayMode;

}

 

After having made the alteration, run your project. At first there was no modification, but if we click the menu arrow of one of the controls, we will see that an option was added to the WebParts menus. It’s the option Edit, see Figure 11. Click in the option Edit and see that WebPart control edition will be displayed, as shown in Figure 12. All the changes made are valid here for the selected WebPart. When OK is clicked upon, the edition control is closed.

 

Figure 11. WebPart Menu Edit Option

 

Figure 12. Editing Webpart layout properties

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.

 

Rodrigo Sendin Silva (rodrigo.sendin@taunet.com.br) is a FATEC-AM graduate technologist. For 10 years he’s been acting with software development, and currently works in the TauNet Consulting as C# developer, in Workflow projects, SharePoint, ASP.NET, Business Intelligence, and Knowledge Management.