Monday, June 30, 2008 : 5:06 AM
- (0 comments)
Recently, I've been working on an update to a feature for SingingEels while at the same time writing an article on how to build an "image manager" using Silverlight. Because we store images (and thumbnails) in our database, we retrieve them via their ID as a query string parameter. Example:
<a href="Images.aspx?ID=1234" />
This is some very simple code, and there are probably a million articles on how to dynamically retrieve images from a database and display them in a browser.
So, as I was converting our existing functionality into a Silverlight application, I ran into a strange bug. As of right now (Silverlight 2 Beta 2), if you put a query string property in the 'Source' of an 'Image', it'll get ignored. So, if this is your XAML:
<Image Source="Images.aspx?ID=1234" />
Then instead of sending a request to the entire URI, Silverlight chops off everything from the quetion mark onward. Here's a screen-shot of what actually came accross the wire. Notice that the URL doesn't include the query string (as if Silverlight is intentionally truncating it):
Now, to show you that I'm not crazy (and how I got around this issue for my testing purposes). I changed my XAML a little bit to be the following:
<a href="Images.aspx/ID=1234" />
With this simple change in my URL, notice the URL that is being addressed:
Fix The Bug!
My intention for bringing this out isn't to slam Silverlight in any way. It's going to be a great product, and I'm loving it even now. My hope is that someone reads this (who is on the SL dev team), and says "oh yeah, I forgot to fix that"... and then hopefully... they do fix it before launch :)
Monday, June 16, 2008 : 2:49 PM
- (2 comments)
I've been getting into ASP.NET MVC recently, and I have to say, it's a beautiful thing. Being that it's incredibly new and beta (currently preview 3 is out), there are a few bugs that I've run into.
This one in particular has to do with how to add custom HTML attributes to your ActionLinks (which is basically a link to an MVC "page"). The method that you call to create a link is basically this:
<%= Html.ActionLink<"Tag">MyController>(c => c.SomeAction(), "Link Text" %>
This would build a link to the 'SomeAction' view on the MyController... controller :) Now, there are ways to build action links that are a little easier on the eyes, but I'm using this particular overload to show how to add HTML attributes to your link.
So, if you wanted to do some inline CSS, you would change the above code to the following:
<%= Html.ActionLink<"Tag">MyController>(c => c.SomeAction(), "Link Text",
new { style = "color: #f00;" } %>
ASP.NET MVC will automatically parse the "object" parameter at the end there and reflect all properties, then it will add them to your link. So the above code would build a link that looks something like this:
<a href="/MyController/SomeAction" style="color: #f00;">Link Text</a>
Where ASP.NET MVC Loses Me
This approach above seems very 'code cowboy' to me. There is no reason why the last paramter doesn't simply take a params array of name value pairs, or a dictionary, or something like that. Instead, we are now bound to only use HTML attributes that are valid C# (or VB if you're using that language) property names!
I realize this may seem a little dramatic... but while building my navigation, I wanted to add a simple "class='selected'" attribute to my link... and guess what... "class" is a key-word in C#. So this:
<%= Html.ActionLink<"Tag">MyController>(c => c.SomeAction(), "Link Text",
new { class = "selected" } %>
Doesn't compile, and now I'm sad.
Bear With Me
I realize the above complaint is minor... and I am really starting to like MVC, but this just shows me it's not a 100% product yet. I'm excited to see where it goes :)
Thursday, June 5, 2008 : 8:19 PM
- (0 comments)
Don't Forget Performance!
I have to start off by saying that I'm not seriously blaming LINQ to SQL for my bad coding habits, but I will mention that due to all these great technologies that just do stuff for us, we sometimes forget to check for things like performance. Sometimes I take for granted that .NET is ultimately just running code that some mere mortal programmer wrote.
As a result, I just assume that anything that happens outside of *my* code will run at infinite speeds. So, the other day I was reprimanding (not really, but I was semi-lecturing) one of my senior developers for hitting the SQL server in a for loop. Now, to be fair, he's new to LINQ to SQL, and didn't realize that this...
foreach (Task t in myTasks) {
if (t.BillingEntries.Count() > 0) {
}
}
...was going back to the database over and over again :) Just for clarification, the "BillingEntries" property up there is linked from another SQL table.
It wasn't difficult to fix the problem. All we needed to do was get the "count" information in a single hit to the DB, store it in a dictionary, and use it in the for loop, instead of hitting the DB in the for loop.
Where I Had To Eat My Words
So, yesterday, as I was updating some styling on the site (SingingEels.com), I realized that some pages were taking a long time to load (from my local machine). A few pages were taking upward of 10 seconds each... and that's when I realized!
My web server and SQL server are physically next to each other (I think in Colorado, USA), but I live in Florida. So, when I was developing locally, and my web app hit my SQL server in a for loop... well, you get the idea.
Needless to say, I've since then been optimizing the site, and I've included a "server load time" number at the bottom of the site. The moral of the story is, don't forget to check your app for performance issues.