Using a Widget Framework ASP.NET

Dropthings makes use of a widget framework that allows you to focus on providing features that are relevant to the widget itself without worrying about authentication, authorization, profile, personalization, or storage. Widgets get these functions from the widget framework, or the core, shown in Figure

Wid gets are auto matically authenticated,authorized, profiled, and personalized, and they receive storage and utility libraries from the host, which allows you to easily add more function-ality to the web portal in the form of widgets.The core coordinates these services.

Wid gets are auto matically authenticated,authorized, profiled, and personalized

More over, you can build widgets independently of the host project. You don’t need the whole web portal’s web application source code in your local development computer to build wid gets.All you have to do is create a regular ASP.NET 2.0 web site, create a user control, make it do what it’s supposed to do in a regular post back model(don’t worry about Java Script),implement a little interface, and you are done!

You don’t have to worry about Ajax and Java Script with the widget framework I have created for Dropthings.The architecture allows you to use regular ASP.NET 2.0 controls, Ajax Control Toolkit controls, and any extender in ASP.NET AJAX. Full server-side programming support is also included, and you can use.NET 2.0, 3.0, or 3.5, as well as regular View- State and store temporary states. ASP.NET Cache can be used to cache widget data.

This approach is far better than what you would find in any current web portal where you have to build the whole widget using only Java Script, bide by specific API guidelines,and follow a strict “no postback” model (see Figure).

In the Drop things widget frame work,the core does authentication and authorization using the ASP.NET membership provider. This allows the widgets to get the communication bet ween the wid get and the core is done via a wid get container. The wid get container hosts the actual widget and works as a middleman. The widget container knows which widget instance it is hosting and provides it with services like persistence service or event notification.

A page hosts one or more wid get containers,but each widget container hosts only one wid get inside it (see Figure).

A page contains a collection of wid get containers where each wid get container contains one wid get

A page contains a collection of wid get containers where each wid get container contains one wid get

A widget’s code is straight for ward,and just like a regular web control,you can do stuff inside Page_Load.You can also get events raised from ASP.NET user controls.Widgets are similar to Share Point Web Parts,but one advantage over Web Parts is that you can use ASP.NET user controls instead of custom controls.User controls give you access to Visual Studio, which you don’t have with custom controls.You can also make a widget in one .ascx file, which requires no compilation into DLL or deploying that DLL to a server—just copy the .ascx file from the web folder and it is ready to use.

For example, say you wanted a widget that shows photos, perhaps from Flickr.You can write the widget as a user control and, in the control code, handle events the usual way for a user control. The following bit of code displays the photos when the control is loaded onto the page:

protected void Page_Load(object sender, EventArgs e) { if(!base.IsPostBack)
this.ShowPictures(0);
else
this.ShowPictures(PageIndex);
}

To give the widget LinkButton controls to move between photos, write event handlers for the buttons to include navigation code, just as you would for any serverbased navigation:


The ASP.NET page cycle works the same as ordinary page processing. Inside the widget, you can use any ASP.NET control and write code for its events.

The Container provides the widget’s container and frame, and defines a header and a body area. The actual widget is loaded inside the body area at runtime by the widget container.For each widget on the page, the core creates one widget container, and then the widget container dynamically loads the real widget inside its body area. The widget container is part of the framework and you only have to write it once (see Figure). However, widget developers don’t have to write containers because they write the actual widget.

A wid get container is an ASP.NET web control that has a header and a body part, which is where the widget is loaded

A wid get container is an ASP.NET web control that has a header and a body part, which is where the widget is loaded

The widget container is a user control that is dynamically created on the page for each widget instance while the page loads.The widget itself is also a user control that is loaded dynamically by the widget container via Page.LoadControl("...").

The actual widget hosted inside the container is loaded inside an UpdatePanel control.So, no matter how many times the actual widget performs a postback, the widget container does not perform a postback.

Designing the Widget Container

Designing a good widget container is a matter of finding the right combination of UpdatePanels.It is a bit difficult to first decide the best distribution of ASP.NET controls inside an UpdatePanel.Putting the whole widget container inside one UpdatePanel works well enough, and there is only one UpdatePanel per widget container,so the overhead is small.But a problem surfaces with the extenders that are removes existing HTML elements rendered by ASP.NET controls and creates new ones. As a result, all the extenders attached to the previous HTML elements are destroyed, unless the extenders are also inside the UpdatePanel. Putting extenders inside the UpdatePanel means that whenever an UpdatePanel control is refreshed, a new instance of the extenders is created and initialized. This slows UI update after a postback, noticeably so when working with widgets on the page.

You could separate the header and body areas into multiple UpdatePanels—one UpdatePanel would host the header area and another would host the actual widget.This would allow you to change something on the widget and refresh the body widget,but not the header, so the extenders that are attached to the header (e.g., an extender for drag and drop) are not lost. But this means that all the extenders attached to the header controls must be inside the header UpdatePanel, which will affect performance. So, although separating header and body areas into multiple extenders does provide some performance improvement, it isn’t as much as you need(see Figure).

A widget container with two UpdatePanels, one for the header area and one for the body area where the real widget is loaded

A widget container with two UpdatePanels, one for the header area and one for the body area where the real widget is loaded

However, for even better performance, what if the header UpdatePanel didn’t contain the whole header,just the title and header buttons? When the header UpdatePanel refreshes (for example,when a user clicks a header button),the whole header is not recreated, only the title and buttons that are inside the UpdatePanel control are refreshed. This way, the drag-and-drop extender that attaches to the header panel can be put outside the UpdatePanel (see Figure).

The final design of the widget container with some elements outside the UpdatePanel control to optimize the performance of the widget

The final design of the widget container with some elements outside the UpdatePanel control to optimize the performance of the widget

The WidgetContainer implementation is quite simple. There is a header area that contains the title and the expand/collapse/close buttons, and a body area where the actual widget is hosted. In the Dropthings solution folder shown in Figure , the file Wid get Container.ascx contains the markup for WidgetContainer(see Example ).

The .ascx content for the WidgetContainer


The whole widget container is inside a panel control named Widget. The first child is the header panel, which includes the WidgetHeaderUpdatePanel and contains the content of the header area. Inside of that is the title of the widget, some buttons to

change the edit area,and buttons for expanding and collapsing the widget. The WidgetBodyUpdatePanel, which hosts the real widget at runtime, is also included in the header panel.The real widget is loaded by calling Page.LoadControl(...), and then it’s added to the body panel. The CustomFloatingBehavior extender is also included;it attaches to the widget header and makes the whole widget draggable.



Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

ASP.NET Topics