Time to divulge in a little code issue here. I’m currently working on cleaning up the defect backlog of one of our largest products, and we’ve made more extensive use of jQuery in this application than we ever have before (and for one, I think it’s GREAT!), but it’s also caused us to hit some weird problems that we’ve had to work through.
We’ve been using the great Table Drag and Drop jQuery plugin to deal with reordering quickly and easily in the application. There are a number of pages that implement it, and admittedly, I’m not the one who initially set them up. We had a bit of an issue with the C# codebehind on all of them not properly processing a move from the 1 position up to the 0 position that I had to fix, and was able to do that (after some weeping, wailing and gnashing of code), but this one page refused to even get to the codebehind.
Everything worked fine except for when I moved a row from the 1 to 0 position, and I would get a javascript error that said:
prev().0.id is null or not an object
If I’m honest, not the most revealing of errors (though once I figured it out, it told me exactly everything I needed to know:)). So, I dug through the C# code on each, which was identical (except for variable names), but I was pretty sure that wasn’t the problem anyway, as this was a javascript error being thrown, not a page error.
The jQuery call was exactly the same:
1: function onDropItem(table, row) {
2: var curPanelId = getPanelId();
3: PageMethods.Reorder(curPanelId, $(row)[0].id, $(row).prev()[0].id, onSucceeded, onFailed);
4: $(row).highlightFade({ color: 'rgb(255, 241, 168)', end: '#fff', speed: 1000, final: "" });
5: }
So, it couldn’t be the client side code. The problem, it turns out, was in the markup. In both cases, the rows being moved are contained in ListViews, but I discovered a difference between the two. In the ones that worked, there were no XHTML proper <thead> and <tbody> tags to delineate the rows of the table. In the one that was broken, there were.
Time for that DUH moment when I realized that what was happening was that because of the <tbody> tag, there was no previous table row in the DOM for the jQuery code to access, so it was returning a null row, hence the error.
Now, admittedly, I fixed it by going the easy route and removing the <thead> and <tbody> tags (and it works perfectly now), but I know there’s a proper way to handle this with the tags left in, I’ll just have to play with it.
I Binged (yeah, I said it) for this error and found nothing online, so maybe if somebody else runs into this problem, this post will be helpful. If so, please leave me a comment!
Got a bit of a wake up call this morning when I went to deploy a new WCF Service to our internal web server. We’re going to use it for an external Resume Database to talk to, but initially it will be internal only. Well, what I found out, rather rudely, is that if you assign multiple host headers to an IIS site for WCF, you’ll get this rather unfriendly little error:
This collection already contains an address with scheme http. There can be at most one address per scheme in this collection.
Essentially, it’s finding more than one item to bind to, so it freaks out because WCF doesn’t support multiple IIS bindings for the same protocol. There is a work around, which is to create a ServiceHostFactory, about which more information can be found here: http://msdn.microsoft.com/en-us/library/aa702697.aspx
Maybe that’ll help me remember to do this when I switch this to an external WCF service…
First, what a great past 3 days! devLink 2009 was a raging success in my opinion, and from what the Tweetiverse says, it was well enjoyed. I had a great opportunity to volunteer and assist with the logistics of the conference, and a great opportunity to work with some great people which probably taught me more about life than any of the sessions could have possibly taught me about development.
Still I attended some great sessions, the notes of which are previous posts here, though there are others I attended that I didn’t take notes on, one of which sticks with me. Rob Windsor’s session on LINQ and the functionality that makes it possible in .NET 3.0. He gave some really great examples of Type Inference, Lambdas, etc., and it was a great consolidation of all the great new technologies that work with AND independent of LINQ.
But the one “session” I haven’t been able to get out of mind is the final session of the conference which was a panel discussion recorded for Dot Net Rocks which will soon be released. The topic of the discussion was, “Has Software Development Gotten Too Complex?”
I took the opportunity to add a comment to the discussion, in which I expressed my opinion that the root of the problem with software development complexity lies in the developers themselves. As a developer, I’m as guilty of this problem as most are, so I know all too well that developers LOVE to make simple things more complex. Essentially, I said that ego is a large part of the problem with software development being too complex, in that we developers enjoy making things appear more difficult than they really are, so that we can appear to be more important.
I want to expand some thoughts in this area in this blog post. I speak from my own experience as a developer, as well as my experience managing other developers, and working with other developers. We all like to be superheroes. We like to be seen as great problem-solvers who have the ability to fix anything that comes our way. Just like anybody on earth, we have a need to be important.
Unfortunately, that need to be important, and the need to fix problems tends to give us a “hero complex”. That hero complex then leads us to making simple problems more complex. The interesting thing is that as the tools we use become better and more refined, thus making it easier to fix those simple problems, we then compensate by increasing the underlying complexity. In order to take care of our egos, we then project that complexity on to the business units that need us.
We aren’t alone in this ego-based complication of simple problems. Project managers, CIOs, business analysts, etc., are all guilty of overcomplicating the issue. Government officials have turned red tape into either an art form or a science.
So, how do we fix it? How do we make ourselves stop being a big part of the problem of complexity, and start making it easier for those businesses that rely on us to actually solve their problems?
I’d like to see your answers and comments, and in the next week, you’ll see mine.
Presented by Jeff McWherter – Web Ascender
Formal CTPs and documentation @ www.asp.net
Cutting edge drops, roadmaps, etc @ www.codeplex.com/aspnet
VS10 supports multi-targeting, can support 3.5, 2.0
FX4.0 maintains a high compatibility bar with FX 3.5, they’re really trying to make it a much better experience than from 1.1 to 2.0
VS10 – no more WinForms, now WPF rendered interface improving UI performance
Out-of-band releases (MVC, Dynamic Data, etc) rolled up into FX 4.0
ASP.NET 4.0 Themes
Web-Forms
Ajax
ASP.NET MVC
ASP.NET Dynamic Data
Back to the ‘core’
Presenter – Brad Tutterow
Ruby is a programming language, Rails is a Web Framework built on top of it.
Great Book – RailsSpace (Michael Hartl)
I’ve had this weird bug happening with one of the first apps I wrote using LINQ to SQL, and today, I think I figured out why. The error has been really random, but always involved in importing data into it. In this case, they were trying to import Spot (TV Commercial) data into the database, and they kept getting my least favorite LINQ error of all time: “Row not found or changed.” (Seriously, couldn’t we get something a LITTLE more expressive as an error? But I digress…)
So today, I decided I would run a SQL Server Profile on it, and trace what was getting thrown at the database. Glad I did, as I found out that at the end of it trying to insert 10 SPOT records into the database, it was trying to update a CALL (as in telephone call) record repeatedly. WHY?
Then, I looked at the underlying code, and realized I was using a static DataContext from a Global class. The problem appears to be that the update never completed, and so anytime I called the SubmitChanges() method on that static DataContext, it was still trying to update the database, and failing.
So, lesson learned? Don’t use static DataContexts, as they’ll cause you lots of pain and consternation.
riceboyler is actually Jason Clark, a father of three wonderfully crazy children, husband of one crazily wonderful wife, ASP.NET Developer, Certified ScrumMaster, Latter-day Saint, and sometimes I actually do some things I want to do. :)