ExtJS: Structuring your javascript code (1)

ExtJS and me ;)

In my search for good client application widgets, a few years ago, I started to look at YahooUI.
In these days ("days of yore" would be a tad inappropriate ;) ), YahooUI had some limitations, and only a few "out-of-the-box" widgets for "enterprise" applications.

The following is an approximated history of ExtJS, don't take it for granted... :p

At some point, Jack Slocum forked or bundled, or rewrote a whole lot of YahooUI, known in these days as YahooUI-ext (extension).
This is when I learned about it, thanks to my soon-to-be boss (javascript hacker in his spare time ;)).
Though as the project evolved, and the codebase got almost completely rewritten, the project began to include YahooUI as one of its core mechanims (and therefore YahooUI-Ext was not only an extension to YahooUI anymore), which was the major shift that made the renamed ExtJS a framework in its own right. From now on, YahooUI dependency could be completely removed, and other frameworks could be used as an core mechanism (JQuery, Prototype...).

At some point (version 2.0 and on) a specifically rewritten and optimized extjs mechanism was made available: ext-base. From there on, other frameworks were not even necessary anymore.

Javascript thingy... why OMG why???

In a few previous posts, I've already tried to debunk the javascript monster, in order to show that Javascript is a very good language, and that the monster in the browser is not javascript itself (though as every language, it's far from perfect), but the DOM one has to deal with (which differs from browser to browser).

As a web era guy, I've always felt deeply uncomfortable coding web interfaces with server-side languages (even if they are for rich-client-like applications). It has always made me feel like playing volley-ball knee-deep in liquid honey... (ok this is a weird image, though it conveys the message I guess).

In fact, HTTP is a disconnected protocol, and I've always felt like one should use the best tool on both sides.
Before a few years ago and the dawning of AJAX, the client side was in a "ask-for-page, display-page, submit-form" paradigm which made server-side handling of web sites still relevant.
With AJAX and modern frameworks like ExtJS, it is possible to build your client application with a notepad in an html file, and then provide a backend based on any technology you see fit: JavaEE, .Net, PHP, CGI...
Moreover, if you need to change the UI or refresh it a bit later on, you will have the opportunity to do it without touching the logic-handling backend.

I know for a fact that this ranting is directly (in my case) directed towards frameworks like JSF or GWT (the later being a specific case, as all it does is allowing you to code javascript + HTML + CSS in Java, and also because I think it's a damn good framework).

There are 2 tasks one has to handle with a javascript based framework like ExtJS (in fact 3, because the first is to know a bit more than average about Javascript) in order to achieve productivity:

1. Use an appropriate tooling: Javascript is not compiled, a validation tool is then required (and code completion is a nice-to-have)
2. Try to structure your code properly: This is (sadly) not very much documented.

I'll try to detail the second point in this post. For the first one, I'd recommend the use of Aptana, TextMate, or Spket in Eclipse. Visual Studio seems to have some Intellisense features for ExtJS. Learn more here.

The need to structure

When you download ExtJS, you receive a whole lot of good stuff. Among these a lot of examples...

What is hard to do is to try and begin an application.
Very quickly, you'll end up creating a grid, and asking yourself: "My Ajax server-side request seems to be called and returns JSON/XML, then why is it that my grid doesn't show the records?".
You'll soon see that extending the default stores and readers will allow you to whether use browsers' consoles (when they have one) or message boxes in order to give feedback on potential errors.
By default, the framework's widgets are quite silent about this.

Though all the hooks are in place, allowing you to add the expected behaviour (e.g. a popup when server-side errors occur, or even a retry policy, or displaying a loading icon...).

In order to achieve and more importantly maintain that, a bit of structure is necessary.
This is what I'll try and demonstrate in my next blog post.