The IEBlog has just posted an entry about the behaviour of the BASE tag in IE7. The standard (back to HTML 3.2) says that the base tag should occur once in the document and it should be located in the HEAD tag. The IE implementation for the last few versions has been that references and links will be relative to the last BASE tag specified. IE7 will remove this behaviour to be more standards compliant.

While I agree with standards compliance, this one will hurt. I have built a feed reader application that displays entries that have been obtained from different sites. It is quite common that when people write their blog entries, they include relative references to images and hyperlinks.

I have used the IE BASE tag behaviour to get around the broken link problem that my feed reader would otherwise have. For each entry that I render from XML to HTML, I prefix it with a BASE tag that specifies the base href being the url of the web version of the post. As any relative image and anchor urls would be relative to that page, my feed reader was causing IE to correctly identify all the resource for the entries regardless of the site they came from.

How do I get around this? Any ideas?

Without any nice implementation provided already, I will have to parse the contents of each entry, determine the links that are relative and prefix them with the web address for the entry. Quite ugly.

I don’t mind if they revert the BASE tag implementation to be more standards compliant. It would have been nice if the IE team provided another way to declare a section of HTML as relative to a base url though.

I have been thinking about this a bit recently. When is it the most appropriate to use an interface or inheritance? There are so many advantages and disadvantages with both.

Not that I can go to his talk, but I liked a few of Doug’s comments on the matter.

Interfaces are better for those places where extensibility is the highest requirement. Inheritance is better for those places where reusability is the highest requirement.

You can screw up your software by doing too much of either one, or by neglecting either one.

A couple of weeks ago I was building a queueing system using generics. The main problem I had was that I wanted a little bit of functionality in the queued item, so I wrote a base class for it. That was all well and good, but then I quickly realised that most of my objects already have a base class. As you can’t have multiple inheritance, there goes that idea.

To get around this, I have to change the implementation to use an interface instead. This isn’t a bad thing, but to get the same functionality there will probably be a performance hit. This is because the queue would need to constantly check with eached queued item for its progress status rather than the queued item notifying the queue when its progress status changes.

Other than the performance consideration, I don’t like the interface solution so much because the queue will have to assume that the queued item correctly uses the interface. An interface will ensure that an object has the right signatures, but not whether the code in the implemented interface of the object does what is intended.

Any thoughts?

Did you ever want to know how to spin your pen?

I have been doing it since I figured out a couple of ways in high school. One of the guys at my new workplace has pointed me to this site. Pentrix.com will help you spin with the best of them.

I have been playing with Whidbey ASP.Net over the last week, developing some web custom controls that need to publish some resources along with the control.

I have previously written an article about how to publish resources from the controls assembly in 1.1. This works really well, but requires you to do the resource extraction and HTTP handling yourself. This isn’t a huge problem as most of the code can be reused and is compiled into the resource, therefore very portable. The big problem with it is that after the assembly is referenced by the web project, there is a little bit more work to do to get it working. The developer has to add the httpHandler to the web.config so that the site knows how to intepret the request for the resource.

I built a windows service application for work as a piece of my latest projects large puzzle. One of the annoying things about developing windows services is that debugging them as they start is a big problem. My windows service didn’t suffer from this because it didn’t do anything straight away which gave me time to get my fingers hooked into it. Other people at work however did get their service to start work immediately. Debugging their application caused them no small amount of grief.

Paul Ballard just posted an entry (following on from Mike Diehl’s post) about how to debug windows services from the start. Well worth the read if you have been bitten by this.

I have used XML queries in SQL Server for several years now and I am very impressed with the changes to FOR XML in the latest SQL Server 2005 beta. Unfortunately, there doesn’t seem to be much changed in the OPENXML arena.

I was working with an OPENXML statement the other week and I was sick of writing WITH clauses to define how to interpret the XML data. I looked at the documentation for the WITH statement and discovered that you can specify an existing table and use its schema to interpret the XML.

This was great news as I shape my XML data in a way that is consistent with the table schema that stores the data in the database. I wanted to just specify the table that the data was related to. This prevents having to manually type the schema in the WITH clause and also means that if the schema of the real table changes, namely field size or type changes, the procedures don’t need to be updated unless fields are removed or added.

For the last couple of days at work, I have been developing a new ASP.Net site. Across all the pages in the site, there are some common methods and properties that need to be used. In the case of this new application, I needed to check if the authenticated user has permissions in Active Directory to see the details of the user they are requesting.

The easiest way to achieve this common functionality is to create a base class that inherits from System.Web.UI.Page. Each WebForm code behind page can then inherit from the custom class instead of the default System.Web.UI.Page class. I hit some interesting problems with developing this solution in the VS IDE.

The main purpose of creating controls is so they can be reused in other projects. The beauty of Web Custom Controls as opposed to Web User Controls is that they are compiled into an assembly which can easily be copied between ASP.Net projects.

When I am creating controls, I always have dependencies to support the them. At the very least, I have JavaScript that needs to be rendered for client-side behaviours of the control. I have written several controls that also rely on style-sheets and images to be used with the control. Deployment of these dependencies becomes more than a little nightmare.

Take an image for example. What happens when a control needs to render an image to the browser? It needs to render some HTML like <IMG src= ‘test.gif’ />. The browser then makes a request to the web server for test.gif. Thats all very well and good, but to deploy this control, you not only need to copy the controls assembly to the deployment bin folder, but also need to deploy test.gif to the correct folder to be requested by the browser. Each dependency of the control needs to be copied across each of the ASP.Net projects that use the control. This very quickly becomes a maintenance problem.

We had a Tae Kwon Do graduation this morning. My wife and I both completed a double grading to go to a Green belt. We are now at the start of the intermediate ranks.