Paul Johnson's Technology Musings : ASP.NET

Web Widgets with .Net : Part Two

pajohn — Thu, 26 Jun 2008 00:19:00 GMT

Introduction

This is a continuation of an article about Web Widgets posted previously here.

This article builds upon concepts learned in the first article, so if you haven’t read it, I recommend you start there. It walked through the basic steps to create an HttpHandler to output JavaScript. Here, I will continue with that concept and build upon it by making a dynamic, data-driven, Web Widget.

The full working VS project with code examples for this article can be downloaded here:

http://code.msdn.microsoft.com/Project/Download/FileDownload.aspx?ProjectName=webwidgetsdotnet&DownloadId=2331

The Base project to start with this in this article can be downloaded here:

http://code.msdn.microsoft.com/Project/Download/FileDownload.aspx?ProjectName=webwidgetsdotnet&DownloadId=2407

Events Widget Background

The purpose of the widget we are going to build is to display Developer and IT Pro Events from a data store. The events will be displayed as a list of hyperlinks that will take the user to more details about each event. This is similar to a web widget my group, STO (Server and Tools Online) built for MSDN and TechNet in 2007. This widget displayed events (Live Events, Webcasts, etc) for Developers and IT Pros, targeted towards their interests. The widget has since been replaced, during the latest upgrades to the sites, but a screenshot is below so you can get an idea. Note, the Data Access Layer used in my demo projects is returning example data.

http://i283.photobucket.com/albums/kk303/pajohnms/eventswidgetscreenshot3.jpg

Step 1 : Make it Data-Driven

If you look in the “Demo2 Start Here” project, you will see some new directories and files have been added since Demo1. First, notice the Data directory which contains two csharp files, DAL.cs and Event.cs. This is a very basic Data Access Layer which we’ll use to get example data to pass to JavaScript. Also notice that Core.js file has several functions added. These functions are used to create various controls, tags, event handlers, and to attach scripts.

1) Open up the “Demo2 Start Here” project and navigate to the files in the Data directory.

2) If you open /Data/Event.cs, you will notice the following attributes in the file:

[DataContract] attribute applied to the class

[DataMember] attribute applied to each property in the class

These attributes are what makes this class serializable. We will be serializing the Event Data to a format that JavaScript can use, called JSON. JSON stands for JavaScript Simple Object Notation, and is a simple way to define data structures in JavaScript. The DAL.cs file is our Data Access Layer, and simply has one method in it that will return a generic list of example Events.

3) Navigate to /Templates/Core.js and walk through the methods I’ve added here. We will use these methods in /Templates/EventsWidget.js to create controls, attach scripts, and stylesheets.

4) Navigate to /Templates/EventsWidget.js and notice the code that already exists here. I have created an EventsWidget object, and gave it two methods. We will be calling the render method at runtime to render the widget to the page.

5) Now to write some code. Open up Handlers/EventsWidget.cs. Add the following line to BuildOutput() method to access the DAL.

List<Event> eventData = DAL.GetData(5);

6) Next, open up Handlers/WidgetBase.cs. Add the following method, which we’ll use to serialize our Data to JSON format.

public string SerializeToJson(object obj)

{

var serializer = new DataContractJsonSerializer(obj.GetType());

using (var stream = new MemoryStream())

{

serializer.WriteObject(stream, obj);

return Encoding.Default.GetString(stream.ToArray());

}

This code uses a great feature of .Net 3.5, the DataContractJsonSerializer, which makes the job of serializing to JSON a snap.

6) Jump back over to EventsWidget.cs. Now we can serialize our data and pass it into the JavaScript template. Add the following lines below your GetData() call in BuildOutput().

string eventJsonData = base.SerializeToJson(eventData);

string placeholder = ConfigurationSettings.AppSettings["EventDataPlaceholder"];

output = output.Replace(placeholder, eventJsonData);

7) Notice the following config setting in web.config. This creates a string that we will use as a placeholder for the data in our JavaScript file.

8) Open up Templates/EventsWidget.js and add the following line to the constructor.

this.eventData = {eventData:placeholder};

This variable’s value will be replaced at runtime by the code we added in step 6. Then you can see that this variable gets passed into core.createHyperlinkList(), which loops through the data and creates a unordered list of hyperlinks.

9) Now that we’ve got data passed into our object, we can call the render method to display the widget. Add the following line to /Templates/EventsWidget.js at the very bottom of the file.

ev_w.render();

10) At this point, you can hit this in a browser. You should see a list of 5 hyperlinks from the event data, but they will be unstyled at this point. Next, I’m going to walk through adding a configuration setting to the querystring and adding a stylesheet.

Step 2 : Make it Configurable

Now I’m going to give adopters a way to configure the output of the widget on their site. The easiest thing to configure will be the amount of events to display. It seems quite feasible as an option adopters might want. I want them to be able to configure this in the script block they deploy, so the configuration variable will be sent in the querystring. Let’s start by modifying the middle-tier to accept this parameter.

1) Open /Handlers/EventsWidget.cs

2) Add a private member variable to hold the value for top number of events to display. Add the following line to the top of the class.

private int _topN;

3) Add the following method to the class to take the parameter out of the querystring and set the member variable we just added.

private void GetRequestParameters()

{

_topN = 5;

if (!string.IsNullOrEmpty(Request.QueryString["topN"]))

{

if (!int.TryParse(Request.QueryString["topN"], out _topN))

_topN = 5;

}

4) Reference the method we just added and change the hard-coded 5 value in GetData(5) to GetData(_topN). On the first line of BuildOutput(), add the following line.

GetRequestParameters();

5) Last, let’s add the parameter to the querystring in the script block. I’m going to change the value to 3, so we can tell it’s different from the previous 5 we were displaying.

src="eventswidget.jss?topN=3" >

</script>

6) Now, hit the widget again in a browser. You should now see 3 events listed (or whatever number you pass in).

Step 3 : Make It Pretty with CSS

Now, we’re going to attach a StyleSheet so that it looks a little better. You probably noticed I’ve been adding CSS class names on several elements in the JavaScript code. There is a stylesheet in the project that contains those classes, and now we’ll hook that up.

One important thing to note; when attaching objects such as other scripts, stylesheets, images, etc, you need to use the absolute path to those objects, since they are going to live on your host server. I have created a way to pass in a path from the middle-tier to the client-side tier, so that this doesn’t have to be configured separately for different deployments.

1) Add the widget path data in the middle tier. Open /Handlers/WidgetBase.cs and add the following to the ProcessRequest method. This will replace a placeholder value in core.js to give us the application path on our server.

string widgetPathPlaceholder = ConfigurationSettings.AppSettings["WidgetPathPlaceholder"];

if (output.IndexOf(widgetPathPlaceholder, 0) > -1)

{

output = output.Replace(widgetPathPlaceholder, Request.Url.GetLeftPart(UriPartial.Authority) + HttpRuntime.AppDomainAppVirtualPath);

}

2) Open /Templates/Core.js and add the following line to the constructor.

this.widgetPath = '{widgetPath:placeholder}';

Now, we have a widgetPath property we can use in any widget for attaching scripts, stylesheets, etc.

3) Open /Templates/EventsWidget.js and add the following line inside the render method.

core.attachStyleSheet(core.widgetPath + '/styles/main.css', 'eventsStyle');

This will call the attachStylesheet method in our Core object and pass in the widgetpath parameter we created. This method adds our stylesheet into the head element of the adopters HTML page.

4) View your widget in a browser. The classes from the stylesheet should be applied and it should have a more appealing look and feel.

Note; an adopter now has a default style for the widget, but with CSS they would also have the freedom to modify the style by creating more specific styles for these elements.

Now you have learned a way to create a web widget, using C# middle-tier, and JavaScript client-tier. This useful approach allows rich and easy content syndication that you can now put to use. It is a very powerful technique, and is also fun to build. I personally really enjoy working on a project that encompasses this many techniques, languages and technologies. It keeps development interesting and makes it fun. Enjoy.

Web Widgets with .Net : Part One

pajohn — Wed, 18 Jun 2008 03:23:00 GMT

Web Widgets with .Net : Part One

This two part article is based on a presentation I gave at Tech Ed North America, Developers Week, 2008, about using .Net to create Web Widgets for the MSDN and TechNet sites. Part one will cover the creation of a basic widget, written in C# and JavaScript. Part two will update that widget to be more dynamic using C#, LINQ, JavaScript, JSON (JavaScript Simple Object Notation), and CSS.

Web Widgets : A Simple Definition

The best place to start is to give you a definition of Web Widgets. From Wikipedia.org, the following is a good description: “(a web widget) is a portable chunk of code that can be installed and executed within any separate HTML-based web page by an end user without requiring additional compilation.”

The basic idea is that a consumer site only needs to deploy a simple script block which requires no compilation. We achieve this by setting the script block’s source (src) parameter to a Uri on a separate widget host server. All server side processing is done on the host server, which sends back client-side script to render the widget on the consumer. There are probably hundreds of possible ways to build a Web Widget, but I’m going to walk through one specific example using .Net.

Typically, Web Widgets can be consumed on any domain outside the host domain. However, Browser Cookie data is available in the Request if in the widget is deployed within the same domain as it is hosted. Additionally, Request information such as Server Variables and QueryString are available in any domain.

Let’s Write Some Code : A Basic Widget using an HttpHandler

Now that we’ve covered some background about what we are building, let’s get to work. As I mentioned before, we are going to be using C# and JavaScript to build this. You could really use any .Net language for the Middle-Tier, but I found that the syntactical similarities between JavaScript and C# made switching gears between the two tiers a bit less jarring.

The code for this first example can be downloaded here: http://code.msdn.microsoft.com/Project/Download/FileDownload.aspx?ProjectName=webwidgetsdotnet&DownloadId=2330

Step 1 : Create an HttpHandler Base Class for all widgets to use.

First, let’s create a base class that can be used for multiple widgets. It will handle the basic functionality of an HttpHandler. Note: I chose to use an HttpHandler here in order to avoid the overhead of the ASP.Net Lifecycle. There is no need in this pattern to use Viewstate, Page Events, or Postbacks, so I can avoid all the unnecessary overhead by using an HttpHandler.

1) Create a new Visual Studio C# Web Project and call it “Demo1”

2) Add a new directory called Handlers and add a WidgetBase.cs class file inside this folder. Mark that class as abstract since it will be our base class.

3) Implement the IHttpHandler interface

4) Using the VS2008 IntelliSense context menu, stub out the required members for an HttpHandler

This will add the following interface members…

IsReusable - property to let IIS know whether this handler can be re-used by other threads.

ProcessRequest(HttpContext context)- The main method of a handler. This is where we will do the work to write a response to the browser.

5) Set IsReusable to return false to ensure thread safety – We don’t want any other requests to come in and modify variables

6) Add null reference checks to ProcessRequest, to avoid null reference exceptions

if (context != null && context.Request != null && context.Response != null)

{

}

7) Add an abstract BuildOutput() method that returns a string. We want to force inheritors to use this method.

public abstract string BuildOutput();

8) Add a member variable to hold a reference to the HttpContext object that is passed into ProcessRequest

private HttpContext _context;

9) Response.Write the results of BuildOutput in ProcessRequest, using the Response object in the _context member variable just added in step 8.

_context = context;

_context.Response.Write(BuildOutput());

10) Add Request and Response shortcuts, using _context member variable. We will be using these shortcuts later, in the widgets that use this base class.

/// <summary>

/// Shortcut to Request object

/// </summary>

public HttpResponse Response

{

get { return _context.Response; }

}

/// <summary>

/// Shortcut to Request object

/// </summary>

public HttpRequest Request

{

get { return _context.Request; }

}

That is all the work we need to do in WidgetBase for now. Let’s move on to create a object of type WidgetBase.

Step 2 : Create an EventsWidget class and wire up the handler in IIS

1) Add a new class file called EventsWidget.cs to the Handlers directory

2) Implement the WidgetBase class and stub out the BuildOutput method using the handy VS2008 Intellisense dropdown

3) Create and return a string called “output” in the BuildOutput method and initialize it to the common “Hello World!” value, since this is the first time we’ll run this application.

public override string BuildOutput()

{

string output = "Hello World!";

return output;

}

4) Open an IIS Management Console and navigate down the application you are running this project in. (Create an application if you haven’t already)

5) In the application configuration features view, look for the “Handler Mappings” feature and double click it to see a list of existing handlers.

6) In the “Actions” area of this view, click the link to “Add Managed Handler”

7) Set up the new Managed Handler similar to the settings below.

Request Path: eventswidget.jss

Type: Demo1.Handlers.EventsWidget

Name: EventsWidget

8) The handler should be ready to run now, so let’s check it in a browser. Open up your favorite browser and navigate to the application you’ve been working in. Add the request path you created in step 7 above to the URI to hit the handler you’ve created. You should see a friendly “Hello World!” message on the screen.

Step 3 : Modify the HttpHandler to output JavaScript

1) Add a new directory called “templates” to hold script templates, and add a new file called core.js. This file will be used as a utility class to hold functions common to widgets.

2) Open /templates/core.js and add the following code to setup a namespace, constructor, and class definition for an object called Core. (Note: you should modify the namespace to match your own company or team)

/** Microsoft.Com.SyndicationDemo.Core.js: shared functionality for widgets **/

// Namespace definition : All Widget Classes should be created in this namespace //

if (!window.Microsoft)

window.Microsoft = {};

if (!Microsoft.Com)

Microsoft.Com = {};

if (!Microsoft.Com.SyndicationDemo)

Microsoft.Com.SyndicationDemo = {};

// Widget Core Constructor //

Microsoft.Com.SyndicationDemo.Core = function(message)

{

document.write(message);

}

// Widget Core Class Definition //

Microsoft.Com.SyndicationDemo.Core.prototype =

{

}

var core = Microsoft.Com.SyndicationDemo.Core("Hello from JS!");

The above JavaScript code is using a feature of the JavaScript language to create a class definition, called Prototype-based Programming. When we “new” up a version of this Core object, it will run the code in the constructor and write out a message via JavaScript.

3) Add a method to WidgetBase which will allow us to read the contents of the JavaScript file we just created. Modify WidgetBase.cs by adding the following method:

public string ReadFromFile(string fileName)

{

string fileContents = string.Empty;

if (HttpContext.Current.Cache[fileName] == null)

{

string filePath = HttpContext.Current.Server.MapPath(fileName);

if (File.Exists(filePath))

{

StreamReader reader;

using (reader = File.OpenText(filePath))

{

fileContents = reader.ReadToEnd();

}

HttpContext.Current.Cache.Insert(fileName, fileContents, new System.Web.Caching.CacheDependency(filePath));

}

else

{

fileContents = (string)HttpContext.Current.Cache[fileName];

}

return fileContents;

}

4) Modify EventsWidget.cs to read the JavaScript file using the method we just created. Change the content of the BuildOutput() method to the following:

string output = base.ReadFromFile(ConfigurationSettings.AppSettings["CoreJavascriptFileName"]);

return output;

5) Lastly, lets hook up this handler in a script block so that it actually runs in a script context. Add a new file called default.aspx to the root of the application. This file will serve as a test harness for our widgets. Add the following script block to the new page:

</script>

6) At this point, we can now hit the new default.aspx in the browser. It should display a friendly message from JavaScript. If you do not see any message, try hitting the handler directly to see if it is throwing an error.

In part two of this article, I will use this project as a starting point and make it dynamic. Part two will cover accessing data, passing data to JavaScript, and working with Styles via CSS.