I’ve almost wrapped up porting my ExtJS demo application to ASP.NET. It has been pretty simple so far once I realized I was trying to make it too complex. After getting a handle on ASP.NET MVC, I realized I didn’t need to use WCF for the JSON calls. ASP.NET MVC is pretty slick and has excellent built-in support for returning JSON data via the JsonResult class and Json method.

For the data, I’m using a very simple database I called Demo which contains two tables, City and Country. They look like this:

I’m using Linq to SQL for data access, and everything was moving along quite nicely until I ran into a small problem. In the Java version of my demo application, I used server-side sorting for the grid. How this works is that when you click a column header on the ExtJS Grid, the data store makes an AJAX call to the server controller with the POST data containing two parameters. The sort parameter contains the name of the column in the data store that the sort should be based on. The dir parameter has either the world ASC or DESC, indicating the direction of the sort.

The method signature in my controller which catches this request looks like this:

ASP.NET MVC will automatically map the two POST parameters to the two parameters in the method, since they have the same names. Where I hit a wall though was with Linq.

One of the big design features of Linq is to provide a strongly typed interface for the query language. Since I wanted the orderby statement to be based on the POST parameter, I thought I could do something like this:

Noticing no red squiggles, I assumed this would work. But it doesn’t. The problem is Linq is strongly typed, so it won’t accept a string after orderby. Linq wants something like this:

This would be cool in normal circumstances, but since I need to vary the orderby based on the sort parameter, I would have to do a large if-then block with multiple Linq queries, executing the required one based on the incoming parameter. Since that sounded like a pretty stupid idea, I dug a big deeper.

After much searching, I determined that Linq, as implemented, can’t handle the dynamic queries. But fortunately some other very smart people created a work around in the form of an extension to Linq called the Dynamic Query Library. Scott’s article provides a pretty good introduction. All you need to do is include the Dynamic.cs file in the solution and add the namespace to the imports.

Using the Dynamic Query extension methods, I can now do something like this:

The Dynamic.cs adds a new version of the OrderBy method which takes a string parameter containing the name of the field to sort on and an optional sort parameter. No if-then loops from hell and no more hair pulling trying to find the simplest solution that works.

I would bet the Dynamic.cs stuff ends up in core Linq, as it is simply too valuable for situations requiring dynamic data access, like my ExtJS demo. It also provides similar support for strings to the other Linq commands.

Now that I’ve gotten past the ugliness, I’ll be able to wrap up my ExtJS demo application. I’m adding some additional features to it which demonstrate some of the coolness of ASP.NET MVC, so stay tuned.

About every three months I’ll go through a phase where I’ll get pissed off at Java and take a look at the Dark Side (.NET). This usually lasts a week or two, until I come to my senses, drop my technology mistress and go back to the reliable runtime I’ve known and loved for years. Java has been a forgiving language, and she has taken me back every time.

This time, I’m finally fed up with both of them at the same time. I’m tired of overly-complicated middleware that does not improve things for the users. If someone uses the word “framework” again when talking about either language, I’ll throttle them with my bare hands. I’m looking for simplicity, the cheap thrill that allows me to focus on the layer that adds the most value for the users – the UI.

I’ve dabbled with Ruby on Rails, but she is an opinionated, foulmouthed mistress. Good for the five minute quicky site, but not a stack you’ll want to associate with the next day. She quickly gets bitchy and difficult if you don’t want to do things exactly her way.

Perl and ColdFusion both seemed kinda cool for about 10 minutes before I came to my senses. Python is just too wierd, and she’s been around the block almost as many times as RoR. And I couldn’t get past the sytnax.

My current programming language mistress is the language all “serious” developers love to hate: PHP. Why PHP? It allows me to focus on my UI without the wasted hours of feeding a bloated middle-tier layer. I’m using the CodeIgniter framework (dammit!, said it myself), and am tickled pink with how easily it allows me to pull everything together. No thousand-line XML config files, just simple productivity.

I might come to my senses again and go back to Java, or I might not. I’ve found a fun-loving, forgiving mistress in PHP/CodeIgniter who just wants to get it on, so it might just be time to move on.

I attended my first ever meeting of the Spring Dallas User Group on Wednesday. They had Keith Donald from SpringSource speak about the new Spring WebFlow 2.

Although my team uses the Spring Framework for all the projects, I’ve always had mixed feelings about Spring because I am not a fan of XML configuration. But the Spring Framework 2.5, with annotation-driven bean wiring has really started to change my opinion. I had similar feelings for Web Flow, but the v2 has definitely improved things. While I’m still not that excited about the core Web Flow state engine, they introduced Spring JS (JavaScript), which was very exciting.

Spring JS provide a JavaScript library for decorating pages so that you can add rich widgets for RIA-goodness but still have the page degrade gracefully in less sophisticated browsers. The original version was based around my favorite ExtJS library, but they changed to Dojo when the ExtJS guys shot themselves in the foot with the license change to GPL. This reinforces my opinion that ExtJS really screwed the pooch. They had the chance to be associated with the best Java framework out there, and lost it.

The user group meeting was very interesting and it was a great group of people. Since one of the organizers is a friend of mine, I’m even going to be the guest speaker in July talking about ExtJS and Spring. I’ll share more on how that goes as the presentation starts to take form.

The final part of the Flash Wars series on AppleInsider ended pretty much as I expected. The author ended with a negative slant towards Flash and I would have to agree with him. What was even more interesting were the comments posted in response.

Since Apple has a large artsy following, many of the responses were from the design folks. I’m not real clear on what planet these folks are from. They were linking showcase Flash “site of the year” sites as a demo of what only Flash was capable of. Unfortunately designers create art to impress their peers, not their users, so the Flash sites had counter-intuitive navigation and way too much glitz.

The design crowd also doesn’t seem to realize no one cares about SVG graphics except themselves and banner ad companies. The latter group is pretty much hated, and I have never had a customer ask for SVG graphics. It is pretty clear the Flash crowd is completely detached from reality, which means it is only a matter of time before they are extinct.

So all the Flash developers out there have my pity. Some have spent years mastering a medium most people despise, and they’ll have to look for something else to do. You could almost say Flash is the new PowerBuilder, except that you could at least do productive work in PowerBuilder.

Apple Insider is running a very interesting series of articles about Adobe Flash and its future. The first article in the Flash Wars series covered the history of Flash. The second part jumps in to all the hurdles and competitors Flash faces, from Microsoft to Apple.

I sat in on most the Flex track at Dallas TechFest, and it is an interesting technology. But I also share the same opinion as the author of the AppleInsider artice — Flash/Flex has a rough road ahead of it. One of the biggest points that I think a lot of folks won’t notice in the article is the suggestion that open standards are a competitor to Flex. By open standards, they mean Ajax, JavaScript, CSS and HTML. I reached the same conclusing after playing with some of the first-rate JavaScript libraries out there like JQuery and ExtJS.

ExtJS, in particular, can do about everything Flex can do, and do it without a browser plug-in. It also has APIs around the non-visual aspect of applications that put Flex to shame. Although ExtJS has licensing issues which I’ve griped about before, if you accept it at face value as a commercial product, it really is the best thing going right now for building RIAs.

A friend of mine is helping organize the Dallas TechFest, which is a free conference sponsored by Microsoft, Sun and others. Dallas rarely gets decent technology conferences outside of single-vendor “marketechure” events, so this should be a lot of fun. It will be at the Addison Convention Center, which makes it doubly nice, since I won’t have to drive into the boonies (downtown Dallas).

TechFest has tracks on about everything interesting going on in programming, including the elderly statesmen (.NET, Java) and the young upstarts (Ruby on Rails, Flex). It also has an emerging technologies track, which should be interesting.

Check out the site for registration information. And don’t forget, it’s FREE!

I have never really cared about the GNU General Public License much before. I always regarded it as the license of choice for the real open source zealots and actively steered clear of it based on its viral nature. All the Java open source tools I care about are released under much less-restrictive, user-friendly license like the Apache Software License or variants of the MIT/BSD licenses. But that all changed this week when my favorite JavaScript library, ExtJS, changed their license to GPL v3.

I have been tinkering with ExtJS for a month now, and have really fallen in love with it. You’ll never want to code an html table again once you’ve worked with ExtJS. The library had been dual-licensed as LGPL or commercial. LGPL is much less restrictive than GPL, and it drew a lot of folks in to ExtJS. Without warning, on Monday, the license for ExtJS was changed to regular GPL in a point release. To say the community around ExtJS is a bit agitated would be an understatement.

This change has actually caused me to rethink my opinions about the GPL. I considered it a viral license before, based on the fact it infects everything it touches. Most other professional software developers share the same opinion. But now, seeing what it has done to ExtJS in less than a week, I have decided the GPL is a cancerous license – it doesn’t just infect the host, it kills it.

ExtJS got mindshare by having the LGPL license. Developers were willing to try it, evangelize it, and participate in the community. They felt a sense of ownership in contributing to it and helping the new users on the forums. The surprise change has destroyed that goodwill and the new license makes it very difficult for anyone to take an interest in it. Most companies are strongly anti-GPL, for good reason, so corporate developers won’t be allowed to play with it. And no company is going to go out and buy commercial licenses on blind faith with such a small, unproven software shop.

Now that ExtJS is licensed as GPL instead of LGPL, I expect to see the community evaporate. That leaves ExtJS competing as a purely commercial endeavor against the likes of Microsoft Silverlight and Adobe Flex. The customer-business relationship will be a lot harsher for ExtJS than one of a community-supported open source project. They will become slaves to their biggest clients, effectively ignoring the community that got them the mindshare to begin with.

I can appreciate the ExtJS folks wanting to make money with the work they have done. The dream job of every software developer is to be paid well to work with the technologies you enjoy. But switching to GPL was the wrong way to approach it. Like cancer, the GPL is going to kill the host.

In spite of the inflammatory title, please don’t interpret this to mean Microsoft sucks and Vendor X is a god. I have issues with all the major vendors and have just decided to vocalize about Microsoft first. I don’t really like picking on Microsoft. I’ve worked with them extensively, have been to Redmond, and have worked and socialized with many of their employees. They have all been excellent. Almost every “geek” I have dealt with at Microsoft has been the type of person I would happily have a beer with, which is the ultimate test for a team. So Microsoft doesn’t suck because of its geeks. The problem sits well north of them.

Stagnation

Microsoft’s biggest problem, and the reason Google is eating their lunch, is that Microsoft has stagnated technically. They make their money on the Windows OS and on Office, but both of these are at a dead end. There is no “must have” reason to upgrade either of these any more, and Microsoft’s solution is to try and lock in their enterprise customers with costly maintenance agreements. Like candle makers at the dawn of the electric revolution, Microsoft is desperately clinging to a dead business model, and rather than innovate and adapt, they will abuse their customers to hold on to a monopoly position.

Complexity

Microsoft has gone to the other extreme with their programming tools, .NET. I consider C# to be the only real .NET language. VB.NET is a joke intended to appease the legacy VB6 code monkeys, and no one with any brains would ever initiate a new project using VB.NET. Managed C++ was to appease the other extreme – hardcore MFC/Win32 programmers. But that is such a specialized group that they didn’t really care about .NET. C# itself is the result of a shotgun wedding between Delphi and Java. Microsoft stole the creator of Turbo Pascal (Anders Hejlsberg) from Borland, who created C#. Rather than play nice with Sun and do something beneficial for their customers, Microsoft chose to fracture the market in an attempt to maintain their platform monopoly.

All this would be water under the bridge if Microsoft didn’t continue the make things worse for developers. C# has morphed from a fairly clean Java clone to an absolute monstrosity of complexity. To give the impression of innovation, they have consistently added everything and the kitchen sink to each revision. Code written in the latest version, .NET 3.5, is simply painful to read if the developer actually tries to use all the features Microsoft has thrown in. LINQ is the perfect example of how to make a language unusable.

Enterprise software developers are not the cream-of-the-crop in the developer food chain. Most are minimally skilled and chose enterprise development to avoid having to deal with rapidly changing technology. The reason there are still VB6 developers is because of enterprises. Given their resistance to change, it makes no sense for Microsoft to keep adding in so much to .NET. The only explanation is that Microsoft is trying to appease their partners. Keeping the platform moving ensures there is huge consulting money to be made in “helping” enterprises keep up.

Resistance

Developers are the key to any software platform, and one area where Microsoft has really let them down is through their resistance to Open Source software. Almost every other non-Microsoft programming language (Java, Perl, Python, Ruby, PHP, etc…) has a thriving Open Source community around it that breeds innovation, increases reuse and creates a “survival of the fittest” mentality around technologies. Microsoft is a ghetto by comparison, an intellectual ghost town. All because Microsoft’s only motivation is ensuring vendor lock-in to protect their platform monopoly. This will be their downfall in the end. Go to an emerging technology conference or visit a major university and take a look at what the next generation of geeks is cutting their teeth on. You’ll see mostly Apple or Linux laptops, with very little Microsoft. Windows will not be the dominate platform for this next generation.

In summary, Microsoft sucks because they choose to suck. Every reason that is holding them back is entirely within their control. They are like the 80-old chain smoker on oxygen, dying of cancer, that can’t quit smoking two packs a day. They know it is killing them, but they choose not to do anything about it.

In the past decade, enterprise software development has gone through a major paradigm shift. This shift was the introduction of middleware, a.k.a application servers. The objective of the application server was to break the client-server model and move logic into a middle tier where the application logic could be cleanly broken down into discreet, testable layers implemented with object oriented languages. This push to application servers was driven both by the acceptance of object oriented programming and by vendors eager to make boat loads of money selling their middleware to businesses.

One of the side effects of the push to middleware was that databases no longer mattered. The goal of middleware was to abstract out the database. The thinking was that you designed a clean domain model at the middle tier, and various ORM technologies would map that to your database. Developers, in theory, no longer had to be experts in SQL, DDL, stored procedures and indexes. Application servers were going to save us from all this, turning databases into nothing more than data sources.

Another effect of application servers was the introduction of server controls, or widgets, used to help generate HTML views in the MVC pattern. Examples include tag libraries, JSF and JSTL. The application server would generate the entire view and return the complete HTML document to the browser to be rendered to the client. Applications servers were just reinforcing a similar layer of abstraction at the other end of the stack. Browsers were simply windows into the views being generated in the middle tier.

And then came AJAX. Suddenly, through the magic of web services, JavaScript and the XMLHttpRequest object, the browser proved it could be more than a simple rendering engine for HTML documents generated by the application server. The browser itself proved to be a rich application development environment that could be dynamically updated without making expensive round trips to the server to get full HTML documents. This acceptance of the browser as a platform in its own right is causing another paradigm shift that is going to do to middleware what middleware did to the database – render it irrelevant.

The future of web application development will center around JavaScript and the browser, not on application servers. Browsers will make AJAX requests for JSON data back to services, and no one is going to care how those services are provided. In the same way the application server really didn’t care about the underlying database, the next-generation browser application is not going to care how the AJAX request is fulfilled.

Good web applications will still implement clean, layered abstraction via MVC, but it will be implemented in JavaScript at the browser level, not in Java or C# in the middle tier. The ExtJS library is the best example so far of what the future is going to look like. Other possibilities include Adobe’s Flex and Microsoft’s Silverlight, but both these require plug-ins which the pure JavaScript solution doesn’t need.

It is entirely possible that application servers go the way of the dodo, being supplanted by simpler tools which handle AJAX requests. Web servers will serve the basic content (html, js, css) to the browser, which will then make the AJAX requests to populate the model of the application.

A side effect of all this will be the death of XML used for intra-application communication, to be replaced by JSON. This can’t happen soon enough. I have seen way too many applications use XML internally to pass data around. XML web services were designed for tying together heterogeneous processes across system boundaries and are not an efficient protocol to be used inside a homogeneous system. Unfortunately, developers got “high on XML,” which led us to the mess we have today of trying to use XML Web Services for everything. JSON will kill this silliness through its terseness, performance and ease of use within the JavaScript application layer.

Another possible side effect of the marginalization of application servers and middleware is that databases could start to matter again. I would expect that a smart database vendor will implement connectivity directly via JSON, in the same way they provide JDBC or ODBC connectivity today. The browser will send AJAX requests directly to the database server, which will return a JSON-encoded resultset. Expect to see standardization around what the database JSON request/result protocol looks like.