Lately I've deleted a number of half finished posts and not put much live so this bit of advice is for myself... stop rambling. If I can't keep myself interested long enough to actually finish writing the posts there's no way you lot are going to read them. Most of the missing posts have been the longer essay type that stray from technical issues into pure dribble about software development politics. These tend to be the posts that make my eyes glaze over when reading other technical blogs which is a bad sign.
In future I will stick to posts that are either technical, short and / or ridiculous. In case you were wondering here is a short list of titles you've missed out on:
- University sucks, I'm a better teacher (and modest too)
- BOOB (an essay on the pitfalls of Building Out Of the Box)
- Stop f*cking doing that (a tribute to dumbasses everywhere)
- Agile (our excuse for everything)
If you do want to hear more from me I now have both RSS and Email subscriptions running as you can see in the top right of the page. RSS is probably the better option but Email works well for those that aren't mashing it up already.
I'd also be interested to hear about what effect blogging has had on peoples writing and communication skills, could it be beneficial in general?
23/09/2008 02:58 AM (UTC -07:00)
As you can see I am currently upgrading this blog from the Blogger platform to dasBlog. Most things seem to be working OK and the content is all in tact so I'm happy. The main reason I'm moving away from Blogger is to get more control over the site. There are quite a few changes I will be making here over the next few weeks and having the blog as a real ASP.Net application will make this much easier. I had a few issues getting to this point so if you ever want to make this move read on to save yourself some pain.
64bit dasBlog and IIS7
Both my development machine and my web host are running 64bit IIS7. This causes issues with the default distribution of dasBlog as it relies on a 32bit DLL for it's date picker and does not work in IIS7's new integrated pipeline mode. If you want to know all the details of why this happens Scott Hanselman talks about it in his post on migrating dasBlog to 64bit.
Unfortunately the link Scott provides no longer lists the 64bit version of the DLL however it is included in the source distribution of dasBlog. Look in the lib folder for BasicFrame.WebControls.BasicDatePicker.dll.64bit. I have recompiled dasBlog with the new DLL but have not yet updated my web.config to deal with the new integrated pipeline.
Importing Content From Blogger
My biggest concern about the upgrade was whether the content would survive. As you can see it's gone pretty well but there were a few hiccups. I used the utility provided by Nick Schweitzer to process the content. He provides instructions on getting Blogger to export your blog to a nice XML format and they almost work. Fortunately Nick provides the source to his utility so I was able to make a couple of small tweaks.
The first problem was since Blogger still thinks it's exporting HTML it does not correctly encode for us. A simple string replace to convert these characters to   did the trick. The second problem was that Blogger exported dates in month/day/year format but Nicks code was (correctly) using the culture set on my machine which expected day/month/year format. I added a single line of code to force the culture to en-US and everything worked fine.
Work Left To Do
There is one more thing left to move away from Blogger and that is all my images. Once this done I'll be working through all the site settings, making sure things are set up as I want. I also need to check the RSS feeds are working and that FeedBurner has picked them up.
This is my first post to the new blog and I'm using Windows Live Writer so hopefully everything goes smoothly...
05/09/2008 07:27 PM (UTC -07:00)
I have just put up a post about Tech Ed NZ on the
Intergen blog but I don't want to cross post so head on over there to read it.
04/09/2008 03:22 PM (UTC -07:00)
This was an ASP.Net bug that a colleague of mine requested help with a little while ago. The page in question had a data grid that was being provided with a custom implementation of ITemplate for one of it's columns. Inside this template was a check box with AutoPostBack set to true and a server side event that performed some processing.
When the user clicked one of the check boxes the server side event was fired as expected. When the user clicked on a second check box the event would fire twice meaning that the server side processing had now been performed three times in total! As it turns out the event would fire once for each check box in the grid that was currently set to checked, not an expected behaviour and certainly not a desired one. Initially this seems like a pretty bizarre thing for ASP.Net to do but once you understand a few details of the page life cycle it actually has a reasonable explanation.
Consider the following example code behind which exhibits the behaviour described:
public partial class _Default : Page
{
protected void Page_Load(object sender, EventArgs e)
{
int[] data = new[] { 1, 2, 3 };
repeater.ItemTemplate = new TestTemplate();
repeater.DataSource = data;
repeater.DataBind();
}
}
class TestTemplate : ITemplate
{
public void InstantiateIn(Control container)
{
CheckBox checkBox = new CheckBox();
checkBox.ID = "checkBox";
checkBox.Text = "Check Me";
checkBox.AutoPostBack = true;
checkBox.CheckedChanged += new EventHandler(checkBox_CheckedChanged);
container.Controls.Add(checkBox);
}
void checkBox_CheckedChanged(object sender, EventArgs e)
{
HttpContext.Current.Response.Write("Event fired!\n");
}
}
The following sequence of images shows the user loading the page for the first time, selecting the first checkbox and selecting a second checkbox:
The first hint as to what is wrong with the code is that there is no check for IsPostBack in the page load event. This means that the repeater is being rebound every time and that all of the data being stored in the viewstate is being blown away and recreated. This is a classic problem that every ASP.Net programmer makes at some point. Adding a check so that the data is only bound when the page first loads actually causes the data to stop displaying at all after the first event is fired, what's going on?
Our next clue comes courtesy of the Visual Studio debugger. The following breakpoint is being hit just after the user clicks the first checkbox, note the line highlighted in blue:
Here we are recreating the checkbox inside the page load event. The strange thing is that by the time the page load event is executed we would normally expect checkboxes to already be available with their updated values set and ready to use. The other issue is that when we add the IsPostBack check this line of code is never run which means we are never recreating the checkboxes. Shouldn't the repeater know how to recreate the controls because it has their details stored in viewstate?
This missing link here is that loading of viewstate happens earlier in the page life cycle than the page load event. The repeater is trying to load the postback data but at that stage in the request we have not yet set ItemTemplate to tell it how to recreate the controls. The solution is to set the ItemTemplate before viewstate is loaded which gives us the following:
public partial class _Default : Page
{
protected void Page_Init(object sender, EventArgs e)
{
repeater.ItemTemplate = new TestTemplate();
}
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
int[] data = new[] { 1, 2, 3 };
repeater.DataSource = data;
repeater.DataBind();
}
}
}
Now the page behaves as expected. Taking a look in the debugger we can see that the checkboxes are being instantiated in an entirely different part of the page life cycle, before the viewstate is loaded and the page load event is fired:
As a general rule I would suggest that unless you have a specific need, it will be simpler and more reliable to specify your template in the ASPX file than create it by implementing ITemplate in code. If the template is there in the ASPX with the repeater you will not have any timing issues where the template is not loaded.
If you do find you need to set templates programmatically you will need to have a better understanding of the stages each request goes through. A typical scenario would be swapping in different templates for the repeater depending on what data is loaded and bound to it.
Labels: ASP.Net, Data Binding
04/09/2008 05:33 AM (UTC -07:00)