Deployed First ASP.NET MVC Application

Last week, I deployed my first ASP.NET MVC application at work.  Besides being our first ASP.NET MVC app, it is also the first app where we are testing for multiple browsers; IE7 (using IE8 emulation), IE8, Firefox and Chrome.  And that has taught me a number of things to watch for between the browsers.  The most recent item to catch me was a difference between IE and Firefox in handling “empty” nodes.

If you have a div named “node” and you have the opening and closing tags on separate lines, the jquery statement $(‘#node’).html() will return different results in different browsers.  IE returns an empty string  while Firefox and Chrome return the carriage return and any spaces that might be present.  Since I was checking for an empty string to trigger some processing, it wasn’t working in anything but IE.  Putting the open and close tags for the div next to each other fixed Firefox and Chrome.

I get why Firefox didn’t work.  In fact, I would argue that Firefox & Chrome worked correctly and that IE should not have worked.  My point is that just because you test and have the site working, it doesn’t mean the site works.  If you want true cross-browser compatibility, all web interface tests have to be run against all browsers.

And that begets the real problem.  How do you figure out what browsers and what versions to test?  The list will get very big very quickly and that gets expensive.  While unit tests will help with some of this, they do have limits when it gets to exercising the interface through multiple browsers unless you buy some very expensive tools.  And that’s before even considering the problem of multiple versions of IE or Firefox running side-by-side.

It shouldn’t be this hard to build an “ajaxy” web site that is compatible with the major browsers.

>Mongo – Continued One More Time

>So I’ve done some research and my fears are correct.  In order for me to use an ISP with Mongo, I’d have to get a virtual server.  And, the cheaper virtual servers are out because those won’t let you install software. 

This means Mongo has become a fun experiment for now and it’s back to SQL Server I go.  I will have to remember to look into Mongo and the other non-SQL database options again in a few months to see how things have changed.

>Mongo, Cont’d

>So I’ve been playing with Mongo and I’ve got a nice generic wrapper to convert objects to Mongo Documents and visa versa.  It works pretty well and performance continues to be very good.

And I’ve got an idea for a site that I think will work very well with a Mongo back end.  I am a little concerned about using Mongo though; hosting could be an issue.  I know a virtual server/host would work well but those aren’t as cheap as “standard” ASP.NET hosting.  And since I don’t think my site idea would generate much money (except in my dreams 😉 ), an expensive virtual server is something I’d rather not do.

So now I’m trying to decide if I go forward with Mongo or if I fall back to SQL Server for this site idea.  Oi.