I admit, for all my technical knowledge, among other developers I’m a bit of a luddite. I’ve never owned a game console not made by Nintendo, I run Linux on all of my computers, and my first scripting language was Perl, which I only reluctantly gave up for Ruby a couple of years ago. I’ve not drawn to buy the latest PlayStation, or keep up with the latest desktop PC, or to the hawt new computer language that lets you run your software on 32 cores with only four lines of code. I think the reason is that my attraction to these technologies was never their newness or their cool factor, it was that they were good solutions to problems I wanted to solve. Those problems still exist today, and I argue that while there may be new technologies out there that solve other problems better, they don’t solve the original problems in a way that poses a serious challenge.

Gaming: A Search for Experience

The easiest one to debunk is the coming death of gaming consoles. In a recent interview Richard Garriott, the man behind the Ultima franchise, is reported to have said the following when asked about gaming consoles:

I think we might get one more generation, might, but I think fundamentally they’re doomed. I think fundamentally the power that you can carry with you in a portable is really swamping what we’ve thought of as a console.

And, of course, he’s right about the power of my mobile device. It’s clearly got more power than my old Nintendo or SNES ever had, and I imagine it’s probably more powerful than my current (but aging) generation console, the Wii. Where I don’t agree is with the claim that it’s swamping anything. My phone’s great and all, but it’s never going to replace a game console for me. What makes game consoles great is they leverage my existing investments. Hanging on my wall right now is a big TV, surrounded by comfy couches, and hooked into a 5.1 surround sound system. Today I can go and buy a Wii, a PS3, and an XBOX 360 and all will hook neatly into my existing infrastructure. What’s my phone got that will ever compete with that? Controls that are difficult to use because they have to exist on a flat surface? A screen that is tiny by design? Battery life that can be reasonably measured in minutes when under active load? A network connection that is a faction of my home connection?

Which isn’t to say that the mobile device won’t be a successful gaming platform! Far from it. Publishers that crack the nut of good mobile gaming are going to make bucket-loads of money tapping into a market that has been historical averse to video games. More power to ‘em, I say! But they are trying to solve a new problem: how to attract new non-gaming customers? But see, that’s a problem that game publishers have… it is not a problem I have, or the million of other gamers who grew the gaming industry into a billion dollar juggernaut. Our problem remains the same: how do I play immersive games that best leverage the technology I already own? I don’t want my new 40″ TV to sit idle while I squint at my phone, and I don’t think anyone playing games for the past 20 years wants to either. It’s silly to let such a resource lay fallow. Game consoles solve that problem and do so incredibly well, while giving me customized controllers, fast internet, and a wired power source. If someday the mobile device is created that lets me do all those things, I would suggest that game consoles won’t have been killed by mobile devices, so much as mobile devices became game consoles.

Personal Computers: “It’s not in the box, it’s in the band”

Thirty points if you identified the above quote as coming from Antitrust a highly-decent film about an evil software company who is literally killing its young competitors. There’s a moment in the film where the Bill Gates-esque figure (played by Tim Robbins) turns to the young protagonist (played by Ryan Phillippe) and mutters the above line. This brilliant phrase allows them to overcome some roadblock with the development of Nurv, their amazing new content delivery system that will revolutionize the world. Ahead of its time, Antitrust seems to be making a cloud computing comment way back in 2001… that the solution to their problem wasn’t with the devices, but the network that connected those devices.

Sadly, in today’s world of technology predictions, the ability to differentiate between those two concepts seems rarer and rarer. On more than one occasion I’ve heard it declared that the age of the Personal Computer is over. As evidence, the prognosticator points to Cloud Computing as PC computing’s angle of death. I can only assume these people just don’t understand what Cloud Computing even means when they say such things.

Let’s start with the stipulation that Cloud Computing is a poorly defined term, and it can mean all things to all people. But given that, it still have a reasonable well accepted definition for 2011… it is the process of moving computer resources from specific nodes on the resource graph to arbitrary nodes.

Say what?!

Perhaps an example will help. Consider a media server that stores gigabytes of media files which can be accessed by various client computers. In this example, the resource is storage, because we are talking about the data that comprises these media files. But contrary to what you might have heard, a media server isn’t cloud computing! The relationship I described has been around since we had networks… it’s the standard server/client model where there are discrete resources on specific nodes. What would make this cloud computing is if instead of a single server, there were lots of servers all working together to store the music, but that the client was unaware of this arrangement. The client connects to the “cloud” and just gets the media files like it always has, while the servers work to move the files around ensuring prompt delivery. Now we’ve come to the cloud.

Something should jump out at you about this example… the client didn’t change! And the client in this case is the supposedly dying PC! You see, we still need a specific client to connect to our clouds. Whether we are talking about huge CPU clusters or massive petabyte data arrays, we need clients to make use of these non-fixed resources. To give another example, I often hear it claimed that gmail revolutionized email. And yes, it gave us a radically new user interface, but it didn’t change anything when it came to the storage and delivery of email. The idea of email residing on a server that is universally available has been around since the invention of IMAP in 1986.

Perhaps the doomsayers of the PC era aren’t talking about the cloud so much as they are talking about the different nature of devices that will be able to connect to the cloud. Today I can access my email from my phone, my tablet, and no doubt, someday, my refrigerator. Which is great, I’m all for more options when it comes to data consumption. But the assumption that these devices are going to kill the PC makes the same mistake as the gaming console. If you don’t start by looking at the problem PCs were invented to address, you’ll never understand what it will take to replace the PC.

I propose the PC was invented to give us a way to use computer resources in a productive manner. It follows that to end the PC era, we need to invent a device (or set of devices) that is more productive than the PC. Of course, this doesn’t answer the question of what is productive. That’s going to be a personal evaluation, but I think we can all agree that communicating is a productive task. So, let’s take communicating and evaluate it in the context of the PC and the smartphone.

The smartphone has some incredible advantages, not least of which is that its mobile. But in addition to a mobile network connection, smartphones are phones, and thus are ready for voice communication right out of the box. They also increasingly equipped with video cameras, opening the possibility for video communication. So, it’s got mobility, it’s got voice, and it’s got video. All great stuff… but I’m not the least bit worried about it replacing the PC as the primary form of communication. Contrary to what Star Trek may have lead us to believe, video and audio communication poses few threats to text based forms of communication. The problem with audio and video is it’s all single band. For demonstration, I encourage you and your significant other to break out your smart phones in the same room and start video chatting, simultaneously, with your respective families. Let me know how it turns out. Now, try writing an email to your parents at the same time… easier, right? You can both do it at the same time, because text doesn’t collide with others engaging in the same activity.

Sure, smart phones and tablets do text, but nothing beats a QWERTY keyboard when it comes to text input. The PC form factor provides unrivaled means of creating content. Whether it’s writing text, editing a spreadsheet or cutting up a Photoshop document, the mouse/keyboard/monitor are the gold standard. Sure, you can hook up a tablet to those same input devices, but at what point have you just built a PC in a crazy slim form factor?

In the end, these new devices provide exceptionable mobility, and that’s a powerful answer to the problem: how can I be productive when I’m mobile? But when put to the question, how can I maximize the productivity of my computing resources, it’s gonna fall short. But to those who insist they can ditch their PCs entirely… I say, bring it on! I’m all too happy to have the advantage.

Scripting Languages: Putting Text on a Screen

This last item hits closest to home, because I spend most of my professional day writing in one of a handful of scripting languages, so I get a bit defensive whenever someone says I’m coding in the past. The broad claim here is that content delivery has evolved over the year from static documents, like raw HTML, to dynamic documents powered by a combination of server and client side scripting languages, and that another transformation is coming. Instead of dynamic documents, we are going to be streaming documents… data… media? Actually, it’s not entirely clear what we are going to be streaming, but whatever it is, it’ll come in stream format. As proof of the assertion, the doomsayers point to nodeJS, the revolutionary javascript server.

I lucked out last year and saw a nodeJS demo by its developer at SenchaCon and was admittedly blown away but how awesome it was. There’s no doubt about it, you can do stuff with nodeJS that is harder to do in more traditional languages, and its introducing a whole new generation of developers to the world of functional programming. But it’s not new. Functional programming has been around since the 1950s with the development of Lisp. It’s a crazy powerful, yet mind-boggling, technology. Wrapping it up into a server isn’t really new either, as I understand it. The big plus with nodeJS is that language is Javascript, not some parenthesis laden jumble, and thus modern web developers can jump in with their existing knowledge.

But what about NodeJS suggests the death of scripting languages? For that matter, what about scripting languages suggested the death of static documents? Like before, it all goes back to the nature of the problem needing to be solved. With static documents, we were trying to get information out to the client as quickly and as reliably as possible. Static HTML answered that problem brilliantly (more so than I think anyone expected at the time). With dynamic pages, we had two objectives: (1) allow a page to be built through the combination of a smaller discrete parts; and (2) the customization of content based on the user’s input or environment. But here’s the rub… the best web applications still work with static HTML as much as possible. Caching pre-rendered objects, or whole pages, is essential to any application that is going to deal with significant load. So it’s not that scripting killed static pages, it’s that it enhanced what we could do with it. But a developer who doesn’t learn the basics of serving static content does so at his or her own peril.

So, does NodeJS allow us to solve either of the problems that static or dynamic documents solve? I suppose you can use NodeJS as a dynamic document generator. But, that’s not really it’s strong suit as I understand it. It’s power is the ability to handle multiple concurrent users and allow them to exchange information. Which, like I said, is awesome. But it doesn’t mean we won’t need to serve static pages in the future.

Overstating Death

In part, I realize, I’ve fallen victim to the prognosticators’ bombastic claim. To get press, they seem to need to say more and more outrageous things. No one bothers to print the headline that says “Technology gets incrementally better, most things remain the same.” I worry that too many developers get educated in a world of over-hyped expectations and a thirst for the bleeding edge. This obsession strikes me as dangerous. The point of technology, from a societal standpoint, is to help us solve problems. Being shiny isn’t a good enough reason to discard what came before. If all of the current developers are dancing on the graves of old technology, how will we effectively evaluate it against the latest and greatest?

The next time you read an article that says HTML5 will end the way we think of webpages or that your smartphone is going to replace your tax accountant, stop and ask yourself: what is the problem trying to be solved here, and does this new technology solve it in a way that totally displaces the previous solution, or does it just solve a particular part of the problem in a new way? My personal experience is that, in most cases, technology is rarely revolutionary… and when it is revolutionary, no one sees it coming until it’s already here.

But, this holiday season I found myself in need of a specific icon for a project I’m working on, and the design staff is either slammed or on a well earned vacation, so what’s an enterprising developer to do? Role up his sleeves and get dirty with a graphics application, that’s what! And my success was so complete, I couldn’t help but share in the wonder.

What you’re about to see was all done using The GIMP, but no reason this couldn’t be done in Photoshop or really any program that supports layers and opacity. With that, let’s get started.

The Need

The application I’m building makes use of a great set of freely available icons, which I also use on this blog. Included in that 1000+ icon package are a set of folder icons depicting different types of folders. Some with filetypes, some with pictures, almost anything you could want inside of a folder is represented. Except for “groups”. There’s a whole set of group icons, but no icon for a group folder.

The Building Blocks

Which isn’t to say I started from nothing. As I mention, there were group icons, like the plain group.png:

group.png

I also have the plain folder.png:

folder.png

And as a reference I have the folder_user.png, which is essentially where I want to end up, but with the group icon instead of the user icon.

folder_user.png

And lastly, I have the user.png icon itself:

user.png

Step #1: Resize and Positioning

First I took the original folder.png and moved the folder icon into the bottom-left corner, as all the other folder icons looked:

Step #1 - Folder Positioning

Next I determined that the person in the folder_user.png was only 12 x 12 pixels, while the original user.png was 16 x 16. So I resized group.png to 12 x 12 and then pasted it as a new layer into my work space. I moved it into the upper-right corner, where it would eventually need to be, so that layer looked like this:

Step #1 - Group Positioning

When both layers were made visible, I had the general layout of the final icon:

Step #1 - Final Positioning

Step #2: Overlap

The astute viewer will notice that on the reference folder_user.png icon, the person appears inside of the folder, such that the front flap of the folder is in front of the person graphic. At first I thought I was done for… how was I going to recreate the folder flap in front of the group layer? This is when the true genius struck (at least, for me, as a non-designer!). I copied the section of the folder that is the front flap and create a new layer with just those pixels, like this:

Step #2 -- The Flap Layer

Which I then positioned above the other two layers. With visibility turned on for all three layers, we now get a much closer to our final goal:

Step #2: With the Flap

Step #3: Opacity

After a quick self-congratulatory dance, I realized this icon wasn’t quite right. If you take a look at the reference icon again, you’ll see that the person graphic isn’t quite fully covered by the flap. It’s more that the part of the person that is covered is faded… like, the flap itself is partially transparent. The physics of transparent folder flaps aside, I was determined to get an icon that would match the set, so I set about trying to get this last detail just right.

It was then that I realized I could simply turn down the opacity of the flap layer. With only 75% opacity, I ended up with a layer that looked like this:

Step #3 -- Flap with Decreased Opacity

Because I had only copied the clap to a new layer, not cut the flap, there was an exact copy of the flap behind the top-most flap layer. By turning down the opacity on the flap layer, the group graphic was able to show through a bit as well as the identical full-opacity flap immediately behind. This way the background itself didn’t show through (which would have resulted in blue showing through when the icon was embedded in the webapp). Here’s what the semi-transparent flap looks like with a blue background without the the identical full opacity version behind it:

Step #3 -- Transparency without Full Opacity Backing

So, when we combine it all together, we have the the semi-transparent flap as the top layer, the resized group graphic as the second layer, and the full-opacity folder as the third layer, which gives us the finalized folder_group.png:

folder_group.png

All the above graphics have been at 800% size, so here is the original reference user.png and group.png side-by-side, and then the reference folder_user.png side-by-side with my new folder_group.png.

I think I’m going to apply for a job as a designer now.

You might be wondering how the overturning of a policy I support is a good thing, and the simple answer is process matters. The process matters because not all law is of equal value, and this particular regulation wasn’t the sort of foundation upon which you would want to build a free internet. To understand what I’m driving at, you need a basic understanding of the interplay between Congress, regulatory agencies like the FCC, and the Courts. Here’s a quick set of principles

• Congress doesn’t act unless it needs to — This is generally true in all areas, but especially true in technology policy. Congress, for all its many faults, recognizes it’s the least good way of getting things done. It lacks expertise and is highly susceptible to outside interests whose goals are not always aligned with the public. As such, there are numerous mechanisms in Congress to ensure only a small fraction of bills get approved, even if they have majority support.
• Regulatory agencies are expected to pick up the slack — Congress can sit on its hands because it has already setup numerous agencies to make the sorts of expert technical decisions Congress is not so good at. For example, the recent health care reform bill, while very long, will pale in comparison to the length of the regulations that will eventually be written to implement the same. Those regulations will largely come from the Department of Health and Human Services. When flaws are found in the original bill, it won’t be Congress that tries to fix it, it will be DHHS using its regulatory power.
• Courts act as a check against undemocratic law making — Yes, for all you may have heard from conservatives about courts being undemocratic, it is their responsibility to ensure regulators do not overstep the authority granted to them by Congress. This is a challenging but critical task. Regulators are under heavy pressure from advocates, legislators, and the President to push the bounds of their authority to avoid spending political capital on enacting a statute. It is the Courts job to ensure that this doesn’t get out of hand.

The interplay between these three forces is subtle and complex, and I don’t claim to be anywhere close to an expert. But what I can speculate is that when network neutrality failed in the last Congress it was in part because would-be supporters didn’t feel the issue was sufficiently ripe. Why cast a potentially difficult vote when you can have the FCC do your dirty work for you? Now that the courts have ruled that the FCC lacks sufficient authority, the issue goes back to Congress where we can finally get a good sense of just what kind of political support exists.

In the meantime, the court’s decision tells us something else important: the FCC lacks authority to regulate the internet in whatever manner it sees fit. As anyone in the TV business will tell you, that’s probably a good thing from a content perspective, least we end up with such delightful concepts as “community standards” being forced upon us all. With clear limits on the FCC’s ancillary regulatory powers over the internet, Congress can now draft specific authority for the purposes of network neutrality while avoiding the pitfalls of creating a overbearing internet regulator, but also ensure a durable and lasting legislative framework for a free and open internet.

Then, unrelated to anything I did, MoveOn released this really great video on the Public Option.

That may be the single best piece I’ve seen on the topic.

If you’re not familiar with git as a version control system, I encourage you to check it out. I came from Subversion, which was great… but, at least for me, git is better. Better yet, if you use git with open source projects, you can use github.com for free to host your code, which is pretty cool, and self-hosting isn’t very challenging either. One of the aspects of git I’m just coming to understand is git-submodule. The idea is that there is an external project you’d like to pull into your project, but instead of committing it to your own repository, you want to use the external project’s repository. Lots of reasons to want to do this, such as making it easier to track upstream changes, or reducing the size of your own repository.

Ever since I learned about git submodules, I’ve thought that ExtJS seemed like a perfect candidate. As there is a mechanism to change the library at runtime without changing the code on the file system, there’s very little reason to have the library in your own repository. On top of which, ExtJS is big, so why waste the space. Sadly, the fine folks at extjs.com do not provide ExtJS in git form. There is a subversion repository for commercial clients (of which my employer is) but subversion is not git.

Thus, I have decided to take matters into my own hands. As ExtJS is licensed under the GPL, I have the legal right to redistribute the code. So I created my own git repository just for ExtJS at github which anyone can use as to add ExtJS as a git submodule. I’m still trying to figure out some aspects of git-submodule… like, is it possible to specify a tag from the external repo? If so, I will start adding tags to the repository as new versions are released.

For those who want to jump right into using the repo, here’s the magical incantation you want to run from your project root (change the “public/extjs” part to the relative path you want to install ExtJS at):

git submodule add git://github.com/probonogeek/extjs.git public/extjs
git submodule init
git submodule update

Lastly, if there are any extjs.com folks reading this who object to what I’ve done, please don’t hesitate to contact me. While the GPL gives me permission to do as I’ve done, there is a big difference between legal right and community consent. Right now I’m operating on a sort of tacit consent, but will take the repository down if requested.

However, with the release of Debian/Lenny, Debian/Unstable has seen a flood of new packages including the transition from KDE3 -> KDE4, meaning it was simply no longer an option to avoid KDE4. Sure, I could have switched off of Debian/Unstable, but I’m just not that kind of guy. But I had hopes to delay the inevitable as long as possible.

This morning I could delay no further… too many packages were getting held up and it was time to bite the bullet. To my great pleasure, the upgrade has proven a much more enjoyable experience than last time. Instead of KDE 4.1, Debian/Unstable now runs with KDE 4.2.2 and it is just so much better.

Lots of GUI related stuff has cleaned up, applications work like I remember or have alternative mechanisms that I’m willing to learn, and generally things seem faster. I decided to turn off all of the eye-candy, as my laptop isn’t quite as powerful as one might want. But general CPU use is low enough that the fan doesn’t turn on, unlike the first attempt where it ran non-stop. Perhaps the most important feature enhancement is the introduction of a 12 hour clock! Not that I don’t appreciate 24-hour clocks, but my head just doesn’t work that way and I am otherwise surrounded by 12 hour clocks… it simply wasn’t practical to retrain and switch back-and-forth.

I think my only lasting critique is that KDE 4 was designed for big monitors. Everything seems to take up just a little bit more screen real estate that it used to, which makes a big difference on my tiny laptop monitor (only 14 inches, I think…). The appearance is much more in keeping with Web 2.0 design philosophy, which I generally like quite a bit, but on tiny monitors presents certain challenges. My guess is it will look gorgeous when I try it out my desktop’s 19 inch monitor.

First things first, setup your application by whatever magical incantation is appropriate, in my case:

merb-gen app extjs_demo

Now we have a clean application all ready to go. Next you need to bring ExtJS into your codebase so you will have access to it. As ExtJS is 99% javascript, you will want to install in whatever directory your app will use as its document_root so that HTTP requests can get at it. In merb/rails, that directory is called public/. I recommend against using public/javascripts/, even though it’s right there calling out for javascript files. The way I see it, ExtJS is an external library, while public/javascripts/ is where you put your own application scripts, but reasonable minds can disagree.

Head on over to extjs.com and grab the latests release (2.2.1 as of this writing). Pay attention here… you want to unzip the file in its own directory named extjs-2.2.1 (or whatever version you downloaded). If you unzip the file directly into public/, you’re going to be sorry. Now create a symlink pointing to extjs-2.2.1 called “extjs”.

ln -s extjs-2.2.1 extjs

This symlinking strategy allows you to easily try out new releases of ExtJS and revert back without having to worry about blowing away old versions until you are ready.

Now you have ExtJS installed and can already do a great deal if you were to startup your empty app right this very second and access http://localhost:4000/extjs/docs/index.html with your trusty browser. Your framework may use a different port number (Rails defaults to 3000). With merb properly installed on my system, I can just startup the app from the merb root directory by running:

bin/merb

Your browser should show you the API docs just as if you had accessed them on the ExtJS website. This is going to be your number one place to learn the finner points of ExtJS, and now you have it with you so long as you have your application’s source. Handy for those times you don’t have internet access. If you’re using source control, now is a good time to commit

Next we face an important choice. As we build our application we are going to define different ExtJS subclasses (more on what that means in a later post). Those subclasses need to be loaded into your application via the familiar script tag. But there are two different ways our application can respond the script tags request:

1. Serve static javascript files from public/
2. Serve dynamic javascript files from a controller/view setup

Static files in public/ have the advantage of loading much faster, as they come directly off the file system and skip over the framework’s call stack. Dynamic files from a controller/view are dynamic, which allow the javascript to be custom tailored for the user’s needs. Both have their uses and after a lot of trial and experimentation, I determined the best approach is to use both. Okay, so I lied… there is no choice.

What we are going to do is define the various subclass methods in public/javascripts/. These files do not need to change on a per-user basis, so we get the benefit of the static load time. But any files that require dynamic generation will be done via a controller and a view. But before we go a step further we need to setup your application’s index page.

In my estimation, there are two ways to use ExtJS in your application. You can either use it as a widget set for things like buttons, dialog boxes, and grids in the way you might use jQuery UI. Or you can do everything in ExtJS. For the app I’m building at work, ExtJS powers the entire display of the administrative back-end. The setup I’ll show you today assumes that you’re entire app is going to be driven by ExtJS. If you think you’re going to be less whole-hog, don’t worry, many of the steps will be the same.

First things first, we need a root index page to work with. By default, I get a lovely No routes match the request: / error message when trying to access http://localhost:4000. There are lots of ways to setup an index page depending on your framework, all of which is beyond the scope of this post. What I did with merb was create a controller called “home” and added a route to connect “/” with “home/index”.

Next we need to get the view for home/index looking how we want. Many MVC frameworks use layouts to reduce code duplication between views — which is great — but for us, it’s actually a real problem. So I recommend you disable layouts for the home controller (in merb you just declare “layout false” in the controller file). Now head over to the view for home/index (in merb, it will be at app/views/home/index.html.erb). This file is going to serve as your loading point for all the ExtJS magic you need to make your application sing.

Now, add the following HTML right into the file:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
  <title>Your ExtJS Application</title>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  <link rel="stylesheet" type="text/css" href="/extjs/resources/css/ext-all.css">
</head>
<body>

  <!-- External Dependencies -->
  <script type="text/javascript" src="/extjs/adapter/ext/ext-base.js"></script>
  <script type="text/javascript" src="/extjs/ext-all-debug.js"></script>

  <!-- Application Runner -->
  <script type="text/javascript" src="/home/application.js"></script>

  <!-- App Specific Classes -->

</body>
</html>

Let’s look at the lines that may not seem immediately obvious:

<link rel="stylesheet" type="text/css" href="/extjs/resources/css/ext-all.css">

Loads the ExtJS master CSS file. This has all sorts of CSS definitions that make all the ExtJS widgets look super delicious.

<!-- External Dependencies -->
<script type="text/javascript" src="/extjs/adapter/ext/ext-base.js"></script>
<script type="text/javascript" src="/extjs/ext-all-debug.js"></script>

These two lines load up the ExtJS library itself into your application. Make sure you load them in the order specified here. Couple of important notes here. The first line is the adapter line, and I’m told it allows you to teach ExtJS to play nice with other JS frameworks like jQuery and Prototype. I haven’t played with any of that, so your mileage may vary if you go that direction, here we are using ExtJS with ExtJS. The second line is the monster library include and here you actually have two choices. In development mode, I always load ext-all-debug.js, because Firebug output is far more useful… but in production, you’ll want to use ext-all.js, which has been minified for quicker download to your clients. In a more advanced application, we’d have the view determine which file to send programatically, but we are going to take it slow.

<!-- Application Runner -->
<script type="text/javascript" src="/home/application.js"></script>

<!-- App Specific Classes -->

The Application Runner is the starter pistol of your ExtJS application… the thing which makes it go. We are going to setup a basic one in just a moment. Then under that is where your application specific ExtJS subclasses are going to be loaded. There aren’t any at present, but we will write one shortly and it’s good to have a place ready to put them.

For the Application runner you will need to add an application action to the home controller and indicate that it serves up javascript. In Merb:

  def application
    provides :js
    render
  end

Then create a view at app/views/home/application.js.erb and dump in the following:

Ext.BLANK_IMAGE_URL = '/extjs/resources/images/default/s.gif';
Ext.ns('demo');

// application main entry point
Ext.onReady(function() {

  var viewport = new Ext.Viewport({
    items: [
      {
        region:     'north',
        html:       '<h1 class="x-panel-header">Your Demo Application</h1>',
        autoHeight: true,
        border:     false,
        margins:    '0 0 5 0'
      },{
        region:     'center'
      }
    ]
  });
  viewport.show();

});

The first two lines of code set some global configuration. The first line there is a request from the fine folks at ExtJS to use your own locally hosted single blank pixel instead of theirs (it’s the least you can do). The next creates a namespace for the code you are going to be writing. I’ve chosen the highly descriptive “demo” as my namespace here, but I recommend using a short-hand version of your application. The big advantage of using a namespace is now you can define whatever classes you want without bumping into native javascript classes. All of the ExtJS base classes are namedspaced to “Ext”, so I recommend using something other than that.

Then comes the starter pistol:

Ext.onReady(function() {
  // code goes here
});

If you are familiar with jQuery, this is equivalent to:

$(document).ready(function(){
  // code goes here
});

What it does is ensure the code inside of the block is not executed until the entire page is done loading. Meaning all of the javascript libraries, CSS files, etc. If you try to execute your application code right away, you can’t be sure the environment is full prepped. Wrapping your code in the Ext.onReady method gives you the confidence everything is, well, ready.

Then lastly we’ve got this Ext.Viewport constructor with some configuration parameters passed into the constructor. Don’t worry about the specifics of the configuration at the moment, we’ll talk about Viewports in some other post. What’s important to know is that Viewports setup a full browser window environment to instantiate other components. It is the starting point of any full ExtJS application.

At this point you can save these files, startup your application and go to the index page. You should get a panel at the top that reads “Your Demo Application”. Congratulations, you’ve got an ExtJS application!

One last thing to do before we close down for the day. The Viewport there has application specific configuration variables, and as you will learn in the post on subclassing, that is indicator number one that we should create an ExtJS subclass. To do so, create a file at public/javascripts/demo.viewport.js (note, if you declared a different namespace than “demo” use that wherever I use “demo” in all of the following examples). In the file you just created, paste the following:

demo.viewport = function(config) {

  var base_config = {
    items: [
      {
        region:     'north',
        html:       '<h1 class="x-panel-header">Your Demo Application</h1>',
        autoHeight: true,
        border:     false,
        margins:    '0 0 5 0'
      },{
        region:     'center'
      }
    ]
  };

  Ext.apply(base_config,config);

  demo.viewport.superclass.constructor.call(this,base_config);

}

Ext.extend(demo.viewport, Ext.Viewport, {});

Update your application.js file to read:

Ext.BLANK_IMAGE_URL = '/extjs/resources/images/default/s.gif';

Ext.ns('demo');

// application main entry point
Ext.onReady(function() {

  var viewport = new demo.viewport()
  viewport.show();

});

And under “App Specific Classes” in the index.html file, add:

<script type="text/javascript" src="/javascripts/demo.viewport.js"></script>

Reload the index page and nothing should change. Except now we’ve got the static parts of the application being served from public/javascripts/ and the dynamic parts of the application from the home controller. With this basic framework we are ready to start learning about subclasses and how to organize you ExtJS code.

I honestly can’t imagine a use for this plugin other than someone who blogs about both ExtJS and non-ExtJS topics. But, if you are interested in the plugin, it is available at github.

A few caveats… this plugin is still very much in progress. The ExtJS category ID is hard coded into the code. So, unless your ExtJS category ID == 10, as mine does, the code won’t work. Future releases will allow you to specify which category to load on… and maybe, down the road, allow you to specify which parts of ExtJS to load, as opposed to the whole suite like it’s doing right now.

But here’s the big payoff for all this work. I give you my first embedded ExtJS example:

Now, if you think that was easy, you’ve got another thing coming… took me forever to get that to work. Not because of the ExtJS, but because of all the stylesheet interference with my kick-ass WordPress theme. But I think I’ve got it all sorted out. Here’s the entirety of the code I used to produce the above.

  Ext.onReady(function() {
    button = new Ext.Button({
      text:     "Click me, I won't bite",
      renderTo: 'example-button',
      handler:  function(){
        Ext.Msg.alert("Congratulations","You clicked me!");
      }
    });
  });

And then I defined a DIV on the page with ID = “example-button”. It’s just that easy. I think all the kinks are finally worked out and we can get into some real learning with the next post.

Firebug, the Indispensable Tool

The first central concept to cover is basic tools. Back in the day, javascript debugging involved peppering your code with alert() calls that would popup little messages… like print statements in a scripting language, but way more annoying because they would stop the process until you pressed the “okay” button. But now there is a better way. The better way is Firebug. It’s a Firefox extension that lets you peer into your webpage in ways never before possible. It is absolutely essential to doing ExtJS work, so if you don’t have it, you need to get it. If there is a similar tool for IE, I haven’t encountered it, so even if IE is your target browser, use Firefox for development purposes and just be sure to occasionally test in IE for cross-browser issues.

By now I’m assuming you have Firebug installed. You should have a little bug icon in the bottom right of your browser. If you click on it, a panel will expand showing some Firebug options. You want to enable the Console. Script and Net have their uses too, but for today’s lesson, we want the Console. Turn it on for this blog… the page will reload and then you will see four items printed out to the terminal.

The first is a string I sent to the console with the following Javascript code:

console.log('Hello Word');

By calling the log method on the console object I can send pretty much anything I want to the Console you now see below. Turns out you can send nearly anything to the console and Firebug will let you see all sort of internal data. But I’m getting ahead of myself. Before talking about the remaining items in the FireBug Console, I need to talk about some central features of Javascript.

If you were at all like me, you learned about the basic Javascript native types. Chances are that means you learned the following:

var n = 5; // is a Number
var s = 'Hello'; // is a String
var a = new Array('red','blue',green'); // is an Array

You may have even learned a little more advanced stuff, like:

var t = new Time(); // is a Time object
var a['key'] = 'value'; // is an associative array

And, of course, you learned about functions:

function do_stuff( argument ){
  // stuff gets done
}

That was probably good enough to do all sorts of stuff. But if that’s where you stopped you never really learned the fundamental attributes of Javascript that make it possible to do all the cool stuff that ExtJS does (to say nothing of JQuery or Prototype). There are two critical parts of your education that need reenforcement.

Hashes (actually, objects)

Basic computer science teaches us about arrays and hashes, one is ordered data and the other is keyed data. Each have strength and weaknesses. If all you learned was the above, then you probably came to believe — as I did — that Javascript used the Array type for both. Since it was possible to use both integers and strings as Array indexes, it’s not hard to see why.

addresses = new Array();
addresses['alice'] = '123 Fake Street';
addresses['bob'] = '1600 Pennsylvania Ave';

Sure looks like a hash to me. And in a way it is a hash, because it’s keyed data. But in Javascript there is another more powerful way to create a hash. Except, Javascript doesn’t call it a hash, it is called an object. Behold:

addresses = {
  alice: '123 Fake Street',
  bob: '1600 Pennsylvania Ave'
};

Looks like awfully familiar syntax, don’t it? Like, here’s the same object expressed in Ruby:

addresses = {
  :alice => '123 Fake Street',
  :bob => '1600 Pennsylvania Ave'
}

I honestly couldn’t tell you why it’s an object and not a hash, but there it is. The important part is that you can create arbitrarily complex data structures using this syntax in a single assignment. Oh, and for an additional syntactic win, instead of using new Array(), you can just use []. Which means we can do the following:

persona_data = {
  first_name: 'Alice',
  address: {
    street: '123 Fake Street',
    city: 'Springfield',
    zipcode: '12345'
  },
  favorite_colors: ['blue','green']
};

Now that you see how data structures in Javascript can be very sophisticated, let’s see how you can use the Firebug Console to peer inside. Open up the console again and click on the second row that reads Object first_name=Alice address=Object favorite_colors=[2]. In there you will see the different properties of the personal_data object we created above. You can expand the address property to discover it too is an object with its own properties, or expand the favorite_colors property to inspect an array.

Functions as Properties

It turns out that objects, like the ones above, can hold any type of Javascript native type in one of its properties. Arrays, strings, numbers, other objects… you’ve seen examples of all of that by now. The final piece of the puzzle then is to see that objects can also store functions. In Javascript, a function is just another piece of data that can be assigned to a variable, like this:

var my_method = function(){
  // do stuff
}

Now I can run around with the my_method variable, assign it to other variables, and even execute it. And here in lies the third and final lesson of the post. Consider an object like the following:

var refrigerator = {
  contents: ['milk','eggs','cheese'],
  grab_item: function(){
    return this.contents.pop();
  }
}

Here we’ve got our refrigerator object, it’s got some stuff in it, and we’ve got a grab_item method that returns the last item off the contents array. To call that method we have to use just the right syntactic sugar, which means putting parentheses at the end. Consider the following two lines of code:

  snack1 = refrigerator.grab_item // wrong, snack1 now equals the function
  snack2 = refrigerator.grab_item() // right, snack2 now equals 'cheese'

See, we have to tell javascript we want to actually execute the function, not just assign the data. Firebug confirms this in lines three and four on the console.

Okay, with the concepts of objects and methods down, and Firebug installed, we are ready to start diving into ExtJS. Next ExtJS post will have actual ExtJS examples, I promise… I think I’ve nearly got all the bugs worked out for demoing live ExtJS code.

Okay, now that we are just down to the web developers and the wannabe web developers, lets try and get the basics established so that future posts will have a common language we all agree on… or, at least, that I agree on and that you will be forced to understand to extract anything from my ramblings.

ExtJS describes itself as a “Ext JS is a cross-browser JavaScript library for building rich internet applications.” Which is as good a description as any, if not a tad simplistic. I think a more complete description would be, “Ext JS is a GUI framework for building rich internet applications available under either a commercial or open source license.” The emphasis here is that ExtJS:

1. allows for the quick deployment of reusable GUI components
2. is used to build front ends
3. contains a mixture of javascript, CSS, and binary assets
4. has a dual license model

Let’s break those points down to understand what I’m driving at.

Allows for the quick deployment of reusable GUI components

Let’s talk about the sexy stuff first. ExtJS provides a whole ton of Graphical User Interface (GUI) components that you would expect to see in a modern Desktop Environment, but generally don’t see on the web. There is an outstanding ExtJS Example page that shows off most of what the framework can do.

Here’s a quick and dirty list of the various components:

• grids (like in a spreadsheet)
• tabs
• modal windows
• trees
• enhanced form elements
• toolbars
• menus
• buttons
• sliders
• tooltips
• progress bars

Sadly, I haven’t come up with a good way to demo any of these bits of code in WordPress yet (all JS code is sanitized by default to protect against evil), but it’s something I very much plan to work out. In the mean time, let me show you how easy it would be to create an attractive looking button.

  buttonObj = new Ext.Button({
    text:'Press Me',
    renderTo: 'button'
    handler: function(){
      // button action goes here
    },
  })

Then, all we would need is an HTML DIV element with an ID set to “button” and we’d be done. Once the Javascript had executed it would render the button inside of the designated DIV complete with the handler functionality all ready to go. If all of that is Greek to you, don’t worry, I’m going to explain some of the Javascript basics in a future post.

Is used to build front ends

ExtJS’s primary function is to generate HTML for display via a web browser and to attach behaviors to those HTML elements that the user can interact with. This aspect is more important for what it isn’t, than what it is. What ExtJS shouldn’t be used for is application logic. That’s not to say it cannot be used for application logic, just that down that way is madness, so try to avoid it. Here’s some good reasons to keep application logic out of ExtJS.

• ExtJS talks to your webserver via AJAX, which means you will need backend scripts of some kind to process those requests. As those scripts are closer to the database that will back your application, it is those scripts that serve as the more appropriate vessel for your application logic.
• ExtJS uses Javascript for anything functional, which means you would end up writing your application logic in Javascript. Not to dis on Javascript as a language, but most of us don’t have the experience with Javascript to write clean and maintainable application code.
• ExtJS is more like the View part of an MCV application, and the MCV paradigm does not take kindly to embedding logic into the View. For example, if you put application logic into the view and have two views on the same data, you would need two implementations of the same logic. Talk about code duplication nightmares.

If you are really dead set on making a pure ExtJS application, I wish you all the luck in the world, but I don’t think you’re going to find many of my posts very helpful. Consider yourself warned.

Contains a mixture of javascript, CSS, and binary assets

Here’s where I disagree most strongly with the official ExtJS definition. Yes, ExtJS is a “Javascript library,” but it’s so much more than that. In addition to the javascript files that comprise the core of ExtJS, there is a full 2.3 MBs of CSS and image resource files that go along with it. For the most basic uses of ExtJS, you may never look in the resources directory. But as you begin to understand the deeper relationships in the library, you will begin to see how fundamentally important those CSS definitions are, and how tweaking a few images can give you a wide range of flexibility.

Has a dual license model

If ExtJS were to ever be considered controversial, it would be because of this final point. I didn’t come to ExtJS until late 2008, at which point the library had been around for a while. The story goes that ExtJS used to be available under a more permissive open source license, such that commercial developers could use the code without buying a commercial license. At some point in ExtJS’s product development, the company decided to change the open source license to the strictest of all licenses, the GNU General Public License. This engendered quite a bit of bad blood among those commercial developers, who felt like they were tricked into adopting a library and now either had to cough up the dough for a commercial license, GPL their own works, or start all over again.

My opinion is what it generally is involving the GPL… sounds good to me! If a commercial developer wants to benefit from the work, then they are free to pay for future development by buying a license or they can contribute back to the community. The value of a third option is marginal at best, and more likely to induce free-riding than stimulate community.

My company has the good fortune of being able to buy a commercial license outright, so we do all of our development in a closed source environment, so I won’t be showing any examples from that project. What you will see in these posts is using my own personal copy of ExtJS which I have under the terms of the GPL. Which, by my reckoning, makes any example code I throw up here also available under the terms of the GPL. Of course, a lot of the code will be more functional than expressive, in which case you don’t really need to worry about licenses… just use this to study and build your own.

I think that should do it for our introductory post (clocking in at 1133 words already!). Next time I’ll discuss some basic javascript concepts and then get into some of the GUI elements.