August 2005 - Posts
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.
About a month ago, I was at work thinking about how I was going to take care of my increasing backup requirements. I originally used CD-RWs until my profile got too big. Since then, I have been using DVD-RWs with reasonable success. They fail unpredictably but it was the only mass storage I had. Now it is not enough to backup profiles and photos, not to mention the other 20Gb of other stuff that was never backed up.
Speaking of other stuff, check out the BMW Movies site. It is a couple of years old, but way cool.
I started to look at external USB hard disks. My problem was that I wanted a lot of data to be portable and synchronised between the disk and a computer. I didn't want to spend lots of money and it was going to cost a lot for a nice 2.5" drive and enclosure.
I remembered that I had an 80Gb 3.5" Seagate sitting at home in my desktop, not being used. If I got an enclosure for that drive, then I would be set. It would be a little heavier and couldn't be USB powered (although it seems that a lot of the 2.5" drives need mains power anyway). A $10 eBay win (don't ask how much the postage was...) and I have a present from China.
I put it together and fire it up at work on the work laptop. The computer picks it up and it works like a charm. Later, I connect it to my laptop. I get a connection once, then never again. It knows there is a disk there, but thinks it is uninitialised and then fails to initialise it.
So I am down a little bit of money and have a solution that doesn't work. There isn't much on the internet about it other than suggestions that the cable or the enclosure is faulty or there are bent pins somewhere. After exhausting all software tinkering, I crack the enclosure open to look at the connections and pins. It all looks ok and I check that the jumper setting is set alright. It is on master which is supposed to be correct. I remembered though, that the little slip of engrish that came with it mentioned cable select or master. I put it over to cable select and bingo, my laptop can read it like a dream.
I haven't checked it out on the work laptop yet, but it would be a minor inconvenience if that didn't work, not a deal breaker.
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?
Scott has posted a great write up on the changes to web projects in Whidbey. Check it out
here.
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
blogged a while ago about my struggles to get Whidbey June CTP installed with the April CTP of Yukon. It was really messy. A couple of weeks ago, I did the install again on a work laptop running VPC. The easiest way of installing these is to install Yukon first, not Whidbey. Once Yukon is installed, uninstall .Net framwork 2.0 Beta, then install Whidbey. I can't remember if I had to uninstall the MSXML package after uninstalling the framework but it wouldn't hurt as Whidbey will put it back again anyway.
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.
Whidbey has some new tricks up its sleeve. On the surface, it looks like a great implementation, but I have found some problems with it. There is a good article on MSDN that gives a great overview of how it all works. It is a little out of date though as there have been some changes.
One of the great changes in the new version is that the httphandler is inbuilt (for the webresource.axd url) as it is defined in the machine.config instead of being required in each web sites web.config. The url to hit the resource is found by calling Page.ClientScript.GetWebResourceURL to which you pass a Type (from which the assembly is obtained) and the name of the resource you want.
Like I said, on the surface, this looks great, but there are a few things I don't like about this implementation.
Firstly, this implementation requires that you register the resource with the assembly config as one that can be served by webresource.axd. This is for security. It isn't as bad as registering httpHandlers in the sites web.config because this is in the controls assembly and only has to be done in one place. One problem with this is that it is a piece of the puzzle that could be easily over looked or incorrectly typed. It would be nice if this was a property of the resource rather than requiring the developer to enter <Assembly: WebResource([Name], [ContentType] /> into AssemblyInfo.vb (which is also hidden from the IDE by default).
Secondly, the compiler prefixes the name of the resource with the root namespace of the assembly. This means, for example, that test.gif now turns into MyRoot.Web.Controls.test.gif. This is the name of the resource that must be not only defined in AssemblyInfo.vb with <Assembly: WebResource("MyRoot.Web.Controls.test.gif", "image/gif") />, but also when you call Page.ClientScript.GetWebResourceURL. Very intuitive right?
It is the second point that causes me the most grief. Most people will not know that the namespace has been compiled into the resources name and wonder why web resources don't work in Whidbey. I always have a nice namespace hierarchy for my web controls. Each control is under that namespace. This means that when Page.ClientScript.GetWebResourceURL is called, it can be a little more dynamic by saying Page.ClientScript.GetWebResourceURL(Me.GetType(), Me.GetType.Namespace & ".test.gif").
What happens when the class that calls this is wrapped in a Namespace statement. The resource won't be found. To avoid that problem, the namespace has to be hardcoded to be Page.ClientScript.GetWebResourceURL(Me.GetType(), "MyRoot.Web.Controls.test.gif"). Similarly, the registration of the resource in AssemblyInfo.vb must be hardcoded with the namespace as a string as it is a compile time configuration.
So what happens when the namespace of the assembly is changed? Broken resources all over the shop.
Many people have tried to highlight this to Microsoft's Product Feedback Center (read here, here and here). The first link is the most interesting one. The response from Microsoft is a workaround of removing the root namespace of the assembly, or hardcode the namespace in all of your resource references. This means that each of your classes must be wrapped in Namespace statements, or lose flexibility by hardcoding namespaces.
Why is the resource compiled with the namespace as the prefix to its name? No idea, but what benefit does it bring? I still have no idea. It does have these obvious down sides though. It is a shame that Microsoft have taken the stance on this that they have (read outcome of the first feedback link above).
My ankle isn't broken or fractured, just a nasty sprain. After five days, a bruise has finally seen the light of day.
is a job worth doing well. I am not sure if I have done the job well or not, but the result is a lot of pain. I rolled my ankle quite badly at Taekwondo last night. Hurts a lot.
I am starting to settle into my new job. One of the things I have to get used to in this company is the fact that employees are spread around geographically quite a lot. This means that instant messaging is frequently used.
I like to think that I am a very relaxed kind of person, perhaps even funny on my good days. It has really hit home today though about how poorly technology delivers emotion. It is so easy to misunderstand the written word in an email or instant message. Seems like an easy way for a funny person to get in trouble.
Never start a project unless all resources are available.
I have been looking at ASP.Net in Whidbey over the last couple of days for my new job. I have already come across what looks to be a minor bug with resource handling in the June CTP. Being the faithful soldier that I am, I march over to Microsoft's Product Feedback to see if anyone has raised the issue and put it in if no-one else has.
I have to log in with my passport and it kicks me into the profile centre. The profile centre marks the required fields. I figure I will just update it anyway even though nothing has changed (I don't trust the cancel button). It submits back to the same page and still indicates required fields that need to be filled out. The thing is though, all the required fields are filled out. I tried a few times (you never know) but with the same result. There is a message at the top of the form that says to click cancel if you don't want to fill out the form at this stage. So I click cancel, only to be put back to the same form again.
I can't submit a bug to product feedback because they won't let me past the profile centre (hereby known as Bouncer). This does beg the question of what happens when product feedback has a bug such that no-one can submit bugs.