IT405: E-Portals Development

Building a Web 2.0 Portal with ASP.Net 3.5

Al Zabir, Omar (2008)

Chapter 3: Building the Web Layer using

ASP.NET AJAX
 ASP stands for
Objectives Active Server
Pages

By the end of week 4 you should be able to:

Implement a start page of a web portal.
Understand the various areas of the web page.
Header
Widget gallery
Tab bar
Define a three column widget view.
Load a start page.
Build a drag and drop extender.
Implement a widget container.
Demonstrate updating, saving, editing, adding instance ID, and closing widgets.
Describe building widgets.
Recognize page switching.
Use the profile object.
Implement authentication and authorization, logout and handlers.
Objectives

Web portal challenge: providing almost all of your web applications' functionality on a single
page.
The Use of ASP.NET in Web Layer
1. ASP.NET AJAX provides the framework (via UpdatePanel) for updating widgets
without doing any postbacks.
The ASP.NET AJAX runtime provides a framework you can use to make XML HTTP calls
from within the widgets.

2. It offers a rich collection of Control Extenders that add cool effects like fade in/fade
out, smooth transitions, and client-side animations.
It also provides the framework for building client-side effects using Custom Extenders.
The drag-and-drop behaviour of widgets on the page is built as an Extender.

3. Reuse some extenders from the Ajax Control Toolkit (ACT) to enrich the client user
experience within the widgets.
4. ASP.NET AJAX exposes a handy API that you can use to authenticate against the
ASP.NET Membership application service.
Implementing the Start Page

The Default.aspx page is the Start page of the Ajax web

portal and contains:
The header which shows a search box.
The Add Stuff area where users can add more widgets.
The tab bar.
The columns.
The footer.
The Default.aspx page starts with regular ASP.NET page
syntax.
 Default.aspx Start Page

1. Header Area

2. Tab bar Area

3. Add stuff Area

4. Widget Area
 scripting block
Implementing the Start Page <% %>

The code block:

Turns off all caching. (why?)
Registers the header and
footer web controls.
Adds a reference to the
CustomDragDrop
assembly.
Registers the widget
container control.

ASP.NET directives are instructions to specify optional settings, such as registering a custom control and page language.
The Header Area

The header area displays

the logo, the search bars,
and the Login link.
The script block appears
after the header and is
used for client side
behaviors.
o Calling a web service
during drag/drop.
o Showing/hiding
elements.
Add Stuff Area: The Widget Gallery

Showcases all available widgets.

Users can choose which widget to add to the page from this area.
The Add stuff area is inside a single UpdatePanel control that
contains buttons for adding and hiding widgets.
The Tab Bar

Is inside the UpdatePanel.

Adding/editing tabs does not require refreshing of widgets.
Switching tabs refreshes the tab bar and widget area.
The new tab bar is dynamically created.
The Widget Area

Three column widget view.

There are the three columns below the tab bar reserved for widgets
referred to as the widget area.
The widget area is a simple three-column HTML table.
Each column contains one UpdatePanel and one DropCue.
Widgets are loaded inside Panels named LeftPanel,
MiddlePanel, and RightPanel.
Each widget is dynamically loaded and added inside these panels.
If a widget is on the first column, it is added inside LeftPanel.
The CustomDragDropExtender provides the drag-and-drop
support for widgets.
 When a page is requested, it is loaded
into the server memory, processed, and
Life Cycle of a Page sent to the browser

1. Request A request causes ASP.NET to create the page (or if it can, to instead
use a cached response to avoid running the page).
2. Start The page is created, and page properties set (such as Request, Response
and IsPostBack).
3. Initialization Controls on the page are assigned a unique ID.
4. Load Control properties are loaded. If this is a post-back then the properties are
loaded with values in the viewstate or those posted back to the form.
5. Postback event handling If this is a post-back then any necessary event
handlers for the controls on the form will be called.
6. Rendering View state information is saved, and the form contents rendered.
7. Unload The page has been sent to the client. The Page.Response and
Page.Request objects are no longer available. Any clean up is performed.
Loading the Start Page

There is no code in the Page_Load event; instead, it is in the

CreateChildControls function.
ASP.NET calls this function when it needs to create server-
side controls on the page.
If the dynamically created controls are not in place when the
page loads ViewState, the events will not get fired
properly.
The Page_Load event happens too late.
CreateChildControls is the best place to create all
dynamic controls.
Loading the Start Page

There are three steps involved in loading the full page:

1. Load the user page setup and user setting.
Users setting.
Users page collection.
Widgets only on the current page .
2. Render the tabs that shows users pages.
Dynamically create the widgets on the three columns.
3. Load the widgets on the current page.
Use the Func<> part, called predicate.
Drag-and-Drop Extender

The Ajax Control Toolkit comes with a DragPanel extender used to

provide drag-and-drop support to panels.
It has a ReorderList control, which could reorder the items into a
single list.
Due to limitations of the Ajax Control Kit:
A CustomDragDropExtender and
CustomFloatingExtender is created for the column
containers where widgets are placed.
It provides the reordering support. You can attach this
extender to any Panel control.
Implementing WidgetContainer
WidgetContainer dynamically creates a widget inside its body area.
The container consists only of header and body areas.
The rest is provided by the actual widget loaded dynamically inside the containers
body area.
The settings area viewed when you click edit on the header also comes from
the widget.
WidgetContainer informs the widget only when to show it.

WidgetContainer acts as a bridge between widgets and the core.

The core communicates to the widgets via the container.
The widgets use the cores features via the container.

To prevent errors, set the widget.ID to a specific ID that is always the same for the
same widget instance.
Implementing WidgetContainer
Updating:
Update the expanded property of the WidgetInstance
object.
Update the database row to persist the widgets visibility.
Update the header area by switching between the expand
and collapse buttons.
Inform the widget about the Minimize or Maximize events.
Update both the header and body UpdatePanel.
Implementing WidgetContainer
Saving/Editing:
Click on the title of the WidgetContainer header.
The title switches to a text box and a save button.
Enter a new title, save and set the new title for the widget instance.
This is done by switching between LinkButton, TextBox, and Button.
Clicking save switches it back to the LinkButton showing the new title and hides the text box and
save button.
After the UI changes, the WidgetInstance object is updated in database with the new title.
When clicking the edit button, WidgetContainer informs the widget to display its settings area.
The edit button switches itself with cancel edit button.
The edit and cancel edit buttons when clicked fire the same event.
The SettingsOpen property is stored in ViewState to remember if settings are open or not.
ViewState will always return null until the user clicks the edit button and it sets a true value.
Always check ViewState entries for null before casting them to a data type.
If its null, the default value is false.
Implementing WidgetContainer
Adding instance ID
When rendering a WidgetContainer, an attribute is added to the DIV: InstanceID.
The onDrop event on the client side must know the WidgetInstance ID of the
widget that is moved to call the web service and notify the server which WidgetInstance
was moved.
The additional attribute is rendered by overriding the RenderControl function.
Closing widgets
WidgetContainer cannot close itself.
It must be closed from outside and removed from the pages controls collection.
The container just raises the Deleted event when it is closed, and the Default.aspx
handles the UI update and database changes.
contained widget gets notification and it can then perform cleanup operations
The deleted event is raised.
The Default.aspx removed the widget from the database and refreshed the column.
Building Widgets
First create a simple widget to display photos.
Follow this by followed by another widget to display RSS and Atom feeds.
The widget downloads photos as an XML feed from the web site and renders
a 3 3 grid with the pictures. (flickr)
The photo stream is available as an XML feed.
First obtain an application key from the developer zone and pass it at the end of
the URL.
The URL returns recent photos uploaded by the user as XML.
Pictures are shown dynamically and are not part of the HTML markups that
ASP.NET creates.
Building Widgets
The XML does not contain the URL of the photo file. It needs to be built dynamically.
Download and parse the XML using LINQ to XML.
convert each photo node inside the XML to an object of the PhotoInfo class.
This produces one PhotoInfo object for each <photo> node in the XML.
Paging support has been added to it to select several photos at a time by using the Skip and
Take functions.
This takes the photos from the current pageIndex.
Page index is changed when the user clicks the next or previous links.
The Skip method skips the number of items in the XML.
The Take method takes only the specified number of nodes from XML.
A 3 3 HTML table renders the photos from the collection of PhotoInfo objects.
Use HtmlGenericControl instead of HtmlLinkHtmlLink does not allow you to add controls inside
its Controls collection.
The PhotoPageUrl property of PhotoInfo class gives the URL of the photo.
When the widget loads, it checks whether its a first-time load or a postback.
You need to render the pictures again on postback.
Page Switching: Widgets Load
Widgets load on page in three ways:
1. The very first time they are created; they have no state
at this stage.
2. When a user revisits the page; they load in nonpostback
mode and restore their state from persisted state data.
3. During asynchronous postback; they load in postback
mode and restore their state from both ViewState and
persisted states.

Postback events causes the form to be posted back to the server immediately
Page Switching: Profile Object
The web project uses a Profile object like IsFirstVisit to store a
users state.
Profile object is also used to get the currently visiting users name from the
Profile.UserName property.
The Default.aspx is already full of Profile.Something, and so
are the widget container and the widgets.
Next step: You want to add a new web service and access the Profile
object.
When you type context.Profile from the web service code,
IntelliSense doesnt show any of your custom properties.
Profile Object
At runtime, ASP.NET generates a class looking at the specification provided in
web.config, which becomes the Profile object in .aspx pages and .ascx
controls.
This object is not available in the web service (.asmx.cs) and you cannot see the
custom properties you have added in the Profile object.
HttpContext.Current.Profile will reference the Profile object, its type
is ProfileBase, which does not show your custom properties because the
class is generated at runtime.
To overcome this problem, you have to handcode the profile class in your
App_Code folder and then configure web.config so it doesnt autogenerate a
class but instead uses yours.
Authentication and Authorization
The ASP.NET membership provider and profile provider take care of the
authentication and authorization for the application.
An anonymous identification provider is used, which is not common among web
applications.
Anonymous identification provider generates a cookie in the browser that identifies
the anonymous user.

Web services, which let you modify data, are vulnerable to malicious attacks.
Each web service operation needs to ensure operations are performed only on the
objects that the caller owns.
Such security checks are implemented in the business layer because if they were
implemented in web layer, the logic for checking ownership, which is a business rule,
would get into the web layer.
It becomes a maintenance issue to preserve conformance to such validations in all
places.
Logout and Handlers
The logout page is a great candidate for HTTP handlers
without any UI.
In a web portal, we desire the user starts over with a fresh setup.
We need to clear both cookies and any other cookie that the widget
scripts have used for storing temporary states.
Some widgets can secretly keep track of your logged-in session by
storing info in a different cookie.
Its a security risk to have any cookie left from your logged-in session
after logging out.