If you decide to use the GdnSwfObject server control, you can view the API documentation for instructions on how to use the control.

The final release of the control will be some time in July. This final release will include the new swfobject 2.2 runtime.

If you feel like giving it a shot, pop on over the project at CodePlex and give it a whirl.

Read about some of the rationale from the man himself.

That being said, I am in a bit of a dilemma also with my blog. The current blog software that I use was written by myself and is several years old. There are many good blogging engines out there and I believe that I am going to use one of those. In a way, it is a sad thing to think about. This blog was the first piece of MeWare that I ever wrote and I kind of hate to see it go. But, it has been a good blogging platform and hopefully I can maintain the history that is in this little personal Web outlet.

More to come soon...

Click here to download the sample solution for this tutorial

In ASP.NET, an HTTP Handler is a means by which to process a specific endpoint request. Specifically, an HTTP Handler is used to process specific file types from within your ASP.NET website or application. The .NET Framework gives you a tremendous amount of flexibility and power when creating custom processing for specific HTTP requests. In ASP.NET, an HTTP Handler is any component that implements the IHttpHandler interface. The contract of this interface defines two key members: the IsReusable property and the ProcessRequest method.

• IsReusable: Gets a value indicating whether another request can use the IHttpHandler instance
• ProcessRequest: Enables processing of custom HTTP requests. This is the heart of your custom HTTP Handler. The argument passed to this method is the HttpContext object of the current processing request.

Defining logic for these two members satisfies all that is necessary to create an HTTP Handler. When you have defined your handler, you will register the handler with the ASP.NET application using the <httpHandlers /> node of the Web.config. To register a handler, you must specify three attributes:

• verb: This is the HTTP verb(s) that your handler will be used for when processing requests. The typical options are GET and POST
• path: This is the path of the file to process. In this instance, any file with an extension of .simple.
• type: The fully qualified type name of your HTTP Handler. In our example, this is SimpleHandler

After you have set up your web application using the above settings, you have successfully created and registered a custom HTTP Handler.

Now that you have an understanding of how HTTP Handlers work, let's do something a little fancier with our handler.

In the previous example, we built an HTTP Handler that simply flushed text out to the browser. Although this may satisfy some requirements, most real world usage of HTTP Handlers will be more complex.

Since the HTTP Handler provides us with access to the current HttpContext, we have access to the current HttpResponse object as well. We can use this object to send specific file types to the client. We can also send entire files to the client with the addition of a single HTTP header. In our ComplexHandler example, we will configure the application to handle RSS requests to a blog, download Word documents and flush a custom file to the client, all from the same handler.

The RSS request queries my blog for the RSS feed. It then transforms that RSS feed using a custom XSL transformation to display on a page. This process could very easily be modified to use a custom RSS source or generate only the RSS rather than a transformation of the RSS.

As you can see, HTTP Handlers bring the power of ASP.NET processing to custom file types in an extremely useful way.

His musing was targetted at specific Microsoft applications such as SharePoint 2007 and Outlook 2007. Although I partially agree with his points, I feel that he is missing the main point of distinction: SharePoint is an application - not the web. Shown below are my thoughts that I also posted to the discussion of the blog entry.

Discussion Post:

I really like Tony's columns, but this one has a few points which are not entirely related to one another.

SharePoint is not the web, nor is it simply a website. SharePoint is an application. It is a powerful and highly configurable application that integrates with desktop applications (MS Office), back office applications (Dynamics/CRM), mail servers (Exchange) and yes, even Internet Explorer. Since SharePoint sites/portals are generally secured to only company employees or partners, the environment in which they run is essentially controlled/contained. Unfortunately, much of the integration required by this application is beyond the scope of W3C standards. That doesn't justify the point, but it does clarify it a bit.

Given their past, I know that it is easy to vilify Microsoft in the quest for a standard web. But Tony touched on Microsoft's effort with his mentioning of the rich standards support in VS2005 and Expression Web. The HTML editor in VS2005 will tell you if you are using an element or attribute that is out-dated or deprecated from the current standard. You can also choose to have your entire site examined for WCAG and if you have a violation of WCAG, it will tell you the WCAG section as well as instruct you as to what you must do to correct it. Also, all Microsoft provided ASP.NET 2.0 server controls emit standards compliant markup.

The bottom line is this; SharePoint and Outlook are applications - not the web. Although they use HTML, there is a significant difference. Standards have their place and are a very good thing, and when it comes to providing standards compliant tools for developers, Microsoft has made tremendous improvements.

I have been developing ASP Classic/ASP.NET applications on the IIS platform for 6 years now. I started with IIS5 on Win2K server. The product was good, but the advancements made in the last few years that embrace the .NET Framework have truly been amazing. ASP.NET, now in version 2.0, has taken web development to a level that I would have never imagined possible. It is no wonder that some open source guys (including MIT, where open source was born) are making statements like this:

ASP.NET 2.0 is a much more viable platform for sophisticated apps than it used to be. MIT recently switched from java to C# for 1st year developers and I see .NET as much as J2EE in app jobs. As well, when I go to more sophisticated sites there are alot more .aspx is the URLs these days.

It's taken a number of years for this to happen, but through a few versions of the technology, the .NET Framework it is gaining a level of sophistication and maturity that developers can no longer deny. The fact that the underlying platform is built to run hand-in-hand with IIS is most likely the largest cause for this recent change of market share in the web server market.

The title is The Dark Knight and it once again stars Christian Bale as Batman/Bruce Wayne, and Heath Ledger will play the villain as The Joker. Batman has always been one of my favorite comic book characters simply because he possesses no super-human powers to rely upon. I don't know, it kind of makes the story a bit more attractive.

I personally cannot wait to see how this movie plays out!

Download Solution: _05_2007_MasterPages.zip (16.0KB)

Allowing users to select their own theme for your Web application is a feature that is gaining large amounts of popularity amongst users. ASP.NET 2.0 offers many ways to accomplish a theme implementation for your website, such as specifying a theme name in the <%@ Page %> directive of a Web Form, specifying a Theme in the Web.config file for your application or setting the Theme property of the Page class. All of these options provide a great way for administrators to apply themes to their apps, but there are some significant drawbacks to each:

• Specifying a theme name in the <%@ Page %> directive of each Web Form is a nightmare from a maintainability standpoint. In Web apps that may have hundreds of Pages, you would have to update the Theme attribute in every Web Form.
• Storing the Theme in the <pages/> element of the Web.config file solves the issue of having to update each page individually, but it also comes with its own baggage. If you use the Publish Web Site option in Visual Studio 2005, VS will hard-code the theme name into the Theme attribute of the <%@ Page %> directive on all pages that have any CodeBehind specified. If you then later change the name of the Theme in the Web.config file, all ASPX content pages will reflect the change, but any pages with CodeBehind .dll files in the Bin directory of your app will still use the theme that was specified in the Web.config when you published the site. Also, changing the Theme in the Web.config will cause IIS to recycle the application. Again, this is less than ideal.
• Finally, setting the Theme programmatically by setting the Theme property of the Page is a pretty appetizing solution. Unfortunately, a Theme is applied to an ASP.NET Web Form very early in execution, so you must do so before the Page initializes. This is typically handled in a PreInit event handler for a page. Furthermore, this requires you to create this event handler in every page of your application that uses your Theme.

I know what many of you are saying: Why can't I just specify a PreInit event handler in the MasterPage that is used by all of my pages? Unfortunately this does not work because the MasterPage is first compiled, then applied to the Page. The Page class sets the Theme after the MasterPage has already been applied, thus we are once again stuck.

I have seen many posts on forums that show how to accomplish this through a rather lengthy process of using an HttpModule to set the theme. While this solution works fine, it's a bit of an over complication. To solve this issue we need look no further than one of the most useful techniques in object oriented programming: Inheritance.

By deriving a class from the System.Web.UI.Page class, we are able to create the functionality necessary to give our users a theme rich experience with a simple event handler. In this example, I am using a class named AppCookie to store the theme name and AppPageBase is my Page derived class. The Theme property of the AppCookie class is read from a PreInit event handler that is subscribed to the PreInit event from the body of the AppPageBase constructor.

The event handler body is somewhat simple. A new instance of an AppCookie is created and tested to see if the Theme property is empty. If the property is not empty, the specified theme is applied to the page. If it is empty, the default theme which is defined in the <appSettings/> element of my Web.config file is applied instead.

The last step of the process is to ensure that all pages in the application use our AppPageBase class as the base type for all ASP.NET pages. To do so, we change the inherited class on all CodeBehind class definitions to that of our custom class. We must also change the page base type for all pages in the application that may not use CodeBehind. To accomplish this, specify the pageBaseType attribute of the <pages/> element to be the name of our custom class. Finally, I then added a few <asp:LinkButton /> controls to a Web Form to allow the switching between themes to be done by the user.

This implementation allows the user to control the theme, but could very easily be modified to allow only administrators to control the theme. You could store the selected theme in a text or XML file, or use the Web Configuration API to change the value of the default theme in our app settings. If an admin only theme scenario is what you are facing, I would recommend using an external file to store the selected theme. This way IIS will not restart your app every time you make a theme change, as it would if this data was stored in the Web.config.

Code for Part 1: AppCookie, AppPageBase (A), Web.config 

Although META data in the <head/> of an HTML document does not carry as much weight with regard to search engines as it once did, it is still a valuable compliment to any Search Engine Optimization strategy. Unfortunately, when using a MasterPage in ASP.NET 2.0, we lose our declarative control over META data and must rely on programmatic alternatives. Adding a META tag to a Web Form that uses a MasterPage is accomplished by creating an instance of a System.Web.UI.HtmlControls.HtmlMeta object, assigning values to its properties and then adding it to the Controls collection of the Page.Header control. Obviously, this becomes troublesome when using a MasterPage on a Web Form that is only a content page and has no CodeBehind to perform this operation. Luckily, our AppPageBase can be extended to give us the ability to enter META data directly into the <%@ Page %> directive.

In our example we are creating two properties in our AppPageBase class; MetaDescription and MetaKeywords. These are simple string values that will be used to store description and keyword data. To output these values to the page, we will create and attach an event handler to the Init event of the Page in the same manner as before. The body of the event handler will create an instance of an HtmlMeta object and use the two properties defined earlier to add this to the <head/> of the resultant HTML output. Finally, we specify the values for the MetaDescription and the MetaKeywords as attributes of the <%@ Page %> directive for the Web Form.

If you view the pages, you will see that the theme is applied based on user selection. You'll also note by viewing the source code for page NoCodeBehind.aspx that the META data was properly added to the <head/> of the document without any CodeBehind.

Code for Part 2: AppCookie, AppPageBase (B), Web.config 

In closing, you can see where these two techniques can perform leaps and bounds in the maintenance of an ASP.NET 2.0 Web application. An important note: if you have an ASP.NET content page that you do not wish to be themed in your application, simply specify System.Web.UI.Page as the value of the Inherits attribute of the <%@ Page %> directive. This will override the base type from the Web.config. Also note that this article did not cover caching of user defined themed pages. If you wish to explore your caching options, read the ASP.NET Caching Overview on MSDN.