It was about 7 years ago when I was first introduced to Ext JS. My introduction wasn’t anything overly fancy; it was just an Ext JS grid (version 2!) plopped down on a random webpage. However, from the moment I saw the code for the first time, and how easy it was to configure an awesome and totally Web 2.0-looking grid that could easily interact with the data coming from my ColdFusion (yikes!) application server, I was hooked.

I distinctly remember spending the first solid week of a brand new job racing through my orientation tasks for the day just so I could have some extra time to explore the documentation and experiment with the examples, and then staying up late at home to explore even further. As time went on, I advocated further usage of Ext JS for the company’s apps, wrote some (interesting…) ColdFusion custom tags that wrapped a bunch of Ext JS functionality, and even created a training session with a co-worker (who also went on to work at Sencha!) to describe how awesome and useful the Element APIs could be.

Work kept going, and I focused mostly on server-side development, completely missing out on Ext JS 3, 4 More >

A few weeks ago, I had a scenario come up where I wanted to be able to filter an Ext.data.Store based on a set of criteria, part of which depended upon a value in one of my model’s associations. While this is easy enough to do via filterBy(), it can become a bit unwieldy to use, especially if you want/need the criteria to be dynamically constructed.

As I was thinking about how to best deal with this, I remembered my experiences of using ColdBox’s CriteriaBuilder, which is based on Hibernate’s API of the same name. Using CriteriaBuilder, you can–among myriad other things–produce complex queries and, because it is all DSL-based, criteria can be added in as dynamic a way as you’d like.

This inspired me to experiment with building a CriteriaBuilder for Ext JS.

CriteriaBuilder

CriteriaBuilder allows you to build complex, dynamic queries that can query any data within an Ext.data.Store, including association data. Since I was bored, I created two approaches for interfacing with CriteriaBuilder.

In the first approach, you can use a SQL-like syntax to craft your query. For example:

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.

You are the ruler of an island kingdom on which you have an even number of males and females, all of whom are of marriageable age. What you want to do as ruler is to create a series of perfectly “stable” marriages which will provide a good cement for the durability of your society.

In this scenario, a stable marriage is defined fairly simply as a union in which the man does not prefer another woman over the one to which he is married, while the other women also does not prefer the man over the one to which she is married.

For simplicity’s sake, consider two marriages:

Ron & Stacy

Doug & Marian

Scenario #1

Let’s say that Ron prefers Marian over Stacy, even though he’s married to Stacy. If Marian prefers Doug to Ron, she has no reason to leave Doug for Ron, and so her marriage is considered “stable”. Likewise, since Marian has no reason to leave Doug for Ron, Ron also has no legitimate More >

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 >