Ext JS 5

A while back, I stumbled upon a nice little class in Ext JS: Ext.draw.Color. It’s pretty much what it sounds like: a helper class for dealing with color (shocking!). Behind the scenes, Ext.draw.Color represents an RGB color, but provides a number of helpful methods for transforming the color, such as changing luminosity, converting to HSL values, etc. I can’t sleep right now, so I thought it might be interesting to show a few examples of this in action.

The Proverbial Hello World of Color

Of course, the natural place to begin is at the beginning, so let’s create a color. There’s not much to it. While there are a few other ways to go about it, we’ll use the handy create() method. You can pass a variety of “colorish” arguments to it to create your color. For example, let’s say we want to create the CSS color “yellowgreen”. We can do so in many ways:

As I’ve used Sencha Fiddle, I’ve really come to enjoy how simple it makes testing ideas, exploring aspects of Ext JS, and debugging my code. One of the really nice features is the ability to simulate AJAX requests. While this is REALLY nice for simulating the loading of remote data, one place where it has a gap is in testing a fully-rounded workflow…for example, loading data from the server, modifying it, sending it back to the server, and receiving a successful response.

For these kinds of tasks, there a few options. First, you can set up your own server which your Fiddle code can talk to, either via CORS or JSONP. While this works, it’s a pain. Most of the time the stuff I’m doing in Fiddle is not that involved, so having to mess with a server just for remote communications is a little onerous.

Another option is Parse.com. Using this service, you can create and manage cloud-based data structures. And using their RESTful API, you can retrieve this data, as well as all the other standard CRUD operations.

One of the most common tasks for a developer when developing an Ext JS application is dealing with the complexity of nested components. For example, let’s say that you have a simple Ext.panel.Form definition that resembles something like this:

Form Panel

Toolbar

Save Button

Cancel Button

Field Set

Field Container

Field 1

Field 2

Field Container

Field 3

Field 4

Field Set

Field Container

Field 5

Leaving aside all that Ext JS does behind the scenes to simplify management of forms in general, we see that even a simple form definition like this has a fairly complex structure.

Now to the task at hand: given this complex structure, how do we go about retrieving a given component from within this hierarchy? For example, let’s say that we want to specifically target Field 5. How do we do it?

By Id

One approach that was used in the past was to manually assign an id to the component and use Ext.getCmp() to retrieve it.

If you’ve been paying attention to anything Sencha has been talking about since the release of Ext JS 5, you’ve certainly noticed a shift in emphasis in application structure. With Ext JS 4, Sencha provided a pretty robust architecture for developing scalable applications in an MVC(ish) approach. This was a MASSIVE upgrade from the 2.x and 3.x days in which the kind of plumbing needed to pull off something like this was cumbersome to build and, of course, not native to the framework itself. Despite its shortcomings, 4.x’s MVC provided the tools to build applications on a solid foundation very quickly and in a manner that was scalable and reproducible.

But of course, scale always reveals the shortcomings in architecture. As great as Ext JS 4.x’s MVC is (I still like it…), sufficient scale coupled with lack of foresight on the part of application developers can lead to collisions in events and selectors. Additionally, without facilities for easily creating and destroying controllers, scaling a 4.x app always means a directly proportional increase in resources required to manage an application’s controllers, which (under normal circumstances) exist perpetually from the moment the application is initialized.

Partly in response to these challenges, and partly as a natural evolution of the More >

In my last post, we explored the new routing functionality that has been incorporated in Ext JS 5. I had a lot of great feedback and discussions come from that (thanks!), so I thought I’d add a few more notes about some of the routing functionality that I didn’t discuss in the last post. So without further jabbering, let’s dive in.

Route Conditions

One nice feature of routing in Ext JS 5 is that not only can you add a before handler to the route execution, but you can also filter routes which will be matched based on a regex string.

As written, this route will match any hash in this form, regardless of what actual value is passed for our “id” placeholder. What this means is that if someone gets clever and starts to try to manually hack our hash with some value other than what comes naturally from our application, our before handler is still going to fire on the hacked value, and whatever code is in that handler will execute.

Obviously, we could put some error/hack handling in our before handler, but More >

In the last post, we walked through the steps to get our new Ext JS 5 application setup and running. Now we can start laying the foundation for other areas of the new version that we’d like to explore.

Part of this foundation will be to implement the new routing functionality that has been included with Ext JS 5. If you’ve used Sencha Touch before, this will be very familiar to you. If you’ve never seen it, I think you’ll find it pretty simple to pick up.

We need to get routing setup, however, because we’ll use it throughout the other examples that we’ll explore in future installments. The routing will simply make this process easier…so let’s get started!

So what is routing? In the simplest sense, it’s a way for you to leverage the browser’s normal history stack to maintain application state within an Ext JS application. Since your application is, by default, only one page, the browser’s back and forward buttons don’t do much good out of the box. With routing, however, you can wire particular states of your application to the browser’s history stack, allowing More >

It has been a while since I’ve blogged, and during my absence, Sencha went and released Ext JS 5. If you haven’t already, check out all the new features of both 5.0.0 and 5.0.1. I will admit that I am extremely excited to start using it…especially the MVVM architecture. I’m impressed that Sencha keeps evolving their framework, even so soon after such a radical change to MVC in Ext JS 4. While such adjustments might create frustrations for others, I see it as a good sign that the framework is on a good path and has momentum for the future.

So enough with the free promotional copy. Since I am, like many, just starting to get my feet wet with all the changes in Ext JS 5, I thought it might be interesting to do a series of short articles about some of new features. Over the next few weeks, I hope to cover a number of topics, including (but not limited to):

Routing (hooray!)

Data binding

View models and controllers

Chained stores

Grid widgets

Breadcrumbs

more…!

Let’s get started, shall we?

A New Version, A New App

There is, of course, a migration guide for upgrading your 4.x app to Ext JS 5. But that’s lame. We want to start with something More >