What is a Web Widget?

A web widget is a component, a "a piece of web page", which you can provide for other people to display data coming from your site on their own pages located on different domains. Typically, it contains a bit of complex mixture of HTML, CSS and JavaScript or Javascript frameworks (JQuery, JSON, JSONP etc). You will want to hide that complexity and make it as easy as possible for people to include your widget on their pages.

In other words,web widget is a software widget for the web, a tiny application that can be installed and executed within a web page by an end user on their domain web page. Basically they are derived from the idea of reuse of code.

Desktop Widgets and Web Widgets:

Though, there are wide variety of widgets available in the computer and internet world with many shapes and sizes, two of the major widget types we hat today are Web widgets and Desktop Widgets. Web widgets are intended for use on embedding in webpages and have major implications in areas such as site performance, SEO and even backlink campaigns. Desktop widgets are embedded on local computers, and do not impact SEO or webpage performance.

Why is a web widget?

The most common example of a widget that we see everyday is Google Advertisements. Google ads are produced by simply placing a small piece of code on any web page. But they are not limited to advertisements only. A widget can be anything from a voting poll to a weather forecast to a list of current headlines to a crossword puzzle. You can utilize them in your blog to provide an interactive experience for your readers, or you can place them on your personalized start page to get at information you want to see on a regular basis.

The widget can be embedded in a web page with just two HTML tags: one script tag to load the widget and one container tag ,usually a div, to indicate where we want to put the widget on the page:

<script src="http://example.com/widget/script.js type="text/javascript" ></script>

<div id="sample-web-widget-container"></div>

How to build a Web Widget?

There are wide variety of ways to develop a web widget. You can develop widgets using IFRAME in a very simple and straightforward way, but there are plenty of drawbacks with iframe. It is slow process, resource intensive  and does not give the owner of the widget page an ability to style the widgets they want.

One of the most efficient way to build widget is to dynamically load your widget into someone else’s page, and embed it into an empty DIV or a SPAN tag. The widget will become an integral part of the mashup page.

A mashup is a web page or application that uses and combines data, presentation or functionality from two or more sources to create new services. The main characteristics of the mashup are combination, visualization and aggregation. Mashup is important to make more useful already existing data, moreover for personal and professional use.

All parent CSS scripts will affect the widget, and the owner of the mashup page will be able to easily change the styling of the widget if necessary. When developing such widgets, it is recommended not to provide any styling in HTML (and leave all styling to the mashup page). With this approach, it is the responsibility of the host to properly format the widget.

Before building the web widget, there are few things need to be clear.

• Firstly, HEAD or BODY tags should not be contained in a widget as it is part of the host page. It is obvious that you can have only one HEAD and only one BODY tag on the page.
• You may use a FORM tag in the widget, but you should remember to POST into your ASP.NET form. If you try, your ASP.NET widget code will get control, and as a result, you will be redirected from the host’s page.This is actually a disadvantage of this approach: a widget in this scenario has much greater control over the whole page, and can break it easily: by providing bad HTML formatting, by using malicious JavaScript, by redirecting from the host page etc. So, there should be a much higher trust relationship between the owner of the mashup page and the owner of the widget.(Note:Forget about server-side controls that POST for now)
• Do not use the Microsoft AJAX library. Have one and only one ScriptManager inside of your FORM tag. This will enable Microsoft AJAX JavaScript library to embed its own JavaScript code into your page. This approach is way more complicated than the IFRAME one.

Technologies that can be used to develop a web widget:

1. JSONP. The most challenging problem we have to deal with is to overcome "cross-domain posting" issues. Simply put, we want to obtain some HTML (our widget) from the host different from the one that hosts the mashup page, and embed that HTML into the host mashup page - browsers will prevent such an update. JSONP is a known trick that allows to overcome this browser limitation.
2. JavaScript. Great tools are now available for Internet Explorer (Developer Tools, F12 in IE8; separate install in IE7) and Firefox (Firebug) along with the excellent traffic analyzer Fiddler made JavaScript development finally pleasant - you have a very powerful IDE (almost like Visual Studio) for client-side development.
3. jQuery. jQuery is a very powerful object-oriented client-side JavaScript library. Actually, learning this library made the final judgment call to switch to JavaScript. Since this library already has support for JSONP, that was the logical choice.
4. WCF. WCF is an object oriented way to call the service that provides some business logic. For simple widgets (like the one we're developing here), we could've used a simpler approach (just passing the parameters to the "GET"), but WCF is great if you want to develop a complicated widget with non-trivial business logic and high interactivity.
5. JSON. Don't confuse JSONP with JSON: JSON is a way to package parameters when making a request to the server, while JSONP is a trick to overcome cross-domain posting problems. We know another well known technique that deals with packaging parameters and making calls to the server - SOAP and XML. Apparently, when it comes to JavaScript and browsers, JSON is more preferable because it's much lighter (in terms of parsing, in terms of the size of the final network package). So, we're going to develop a WCF service which accepts JSON parameters and returns a JSONP result.

 
Domain Registration, Web Hosting and Reseller Web Hosting 
Start Web Hosting from just $2.5/Month

Using JSON in your ASP.NET application seems hard until you try it. It will get very convenient as you start using it. It is pretty easy to use an UpdatePanel than JSON. But JSON is easy enough that you may decide to use it over the UpdatePanel under certain circumstances.

The obvious problem with the UpdatePanel is that all of the form data gets posted to the server and all of the server code runs during every update. While there are ways of detecting that the UpdatePanel is causing the postback and thereby limiting the amount of code that runs on the server, you are still left with a full submit of the client form elements to contend with. On a large form, and a form with a lot of view state information, this could be a huge consideration.

On the other hand, JSON only sends the data that is needed for the WebService function it is calling and only returns the data that the WebService function returns. So you end up sending less data, executing less code on the server, and returning less code from the server. This can significantly increase the performance of your application as well as increase the scalability of your application.

However, it will take a lot more work to JSON-enable in cases like GridView, treeview etc. In these case cost of the development outweighs the performance gains of JSON and more likely to stay with the UpdatePanel. So we  have options for using the best one in the most suitable cases.