That title is a bit of a mouthful, but it sums up the issue. Everyone seems to be talking about hackable URLs these days, and it kind of feels like the RoR guys are laughing at us ASP.NET people. It's just such a pain to get it to work right in ASP. They added the RewritePath method which you can call in a BeginRequest handler to redirect the request to a certain script and add on any querystring you want, totally transparent to the user. It's a good start.

The problem is that BeginRequest only fires for requests that come through to the ASP.NET engine, that means that IIS has to pick up on an extension like aspx which is mapped to that handler. So most examples of URL rewriting will offer a hackable URL like /shop/books/fiction.aspx, I can hear the RoR guys chuckling again.

After a lot of digging around I came across what seems to be a very little known solution, wildcard mapping. Basically you can add an application mapping to '.*' in the application config and all requests will go to the ASP.NET engine.

I found one little reference to this in some blog comments by Scott Guthrie, he said the problem with this solution is you can't override the default document on a folder, but if that document is aspx then it doesn't really matter!

Anyway, I saved myself $99 on ISAPI Rewrite, so I'm happy.

Labels: aspnet, urlrewrite

Another ASP.NET 2 "secret" for you, this one courtesy of Ben Wards presentation at BarCamp.
<asp:Label ID="Label1" AssociatedControlID="txtFriendlyName" runat="server" Text="Chosen Name"></asp:Label> <asp:TextBox CssClass="data" runat="server" ID="txtFriendlyName" Text="<%#Person.Name %>"></asp:TextBox> AssociatedControlID will automatically write out the for attribute on the label. Saves you waiting till PreRender to get the right ClientId, and keeps UI logic where it should be. Obviously it's a label element and not a span which is what asp:label normally writes out.

Labels: aspnet

I just had to share this little tip with you. A really annoying problem in ASP.NET 1.1 caused by the fact WebForms are just one big HTML form, is that when you hit enter you never really know what's going to happen, and it's rarely what you wanted. For example, you have a search box and a search button, the search method is attached to the click event of the button. User comes a long, types his query, hits enter, the browser then posts back the form, but hasn't triggered any button clicks. In old multiformed applications you'd have a seperate form for the search control, and the browser would have triggered a click action on the single button in that form (the search button).

Thankfully ASP.NET 2 has a solution for this, you can surround your control in an asp:panel and set a button in it as the default button, then if the user hits enter while focus is on any control in that panel, that button is triggered.

Scott Guthrie has an article on it here.

Labels: aspnet