This document discusses planning the architecture for an application built with Ext JS 4. It recommends defining views, models, stores and controllers before implementation to create a solid foundation. It provides an example of architecting the UI of a music streaming application, balancing view granularity and establishing models, stores and controllers. Planning the architecture upfront helps build flexibility and maintainability.

1. Architecting Your App in Ext JS 4, Part 1 Search
16 Tw eet 16 Like 7
3 Comments
Published Jun 21, 2011 | Tommy Maintz | Tutorial | Easy Ext JS, v4.x
Last Updated Aug 10, 2011
RSS | Responses
This Tutorial is most relevant to Ext JS, 4.x.
The scalability, maintainability and flexibility of an application is mostly determined by the Community
quality of the application’s architecture. Unfortunately, it’s often treated as an afterthought. Tw itter Facebook
Proofs of concept and prototypes turn into massive applications, and example code is Tum blr LinkedIn
copied and pasted into the foundations of many applications. You may be tempted to do this RSS Feed Vim eo
because of the quick progress that you see at the start of a project.
However, the time saved will be relatively low compared to the time spent on having to
Related Posts
maintain, scale and often refactor your application later in the project. One way to better
The Sencha Class System
prepare for writing a solid architecture is to follow certain conventions and define application Nov 29
views, models, stores and controllers before actually implementing them. In this article, we’ll
Architecting Your App in Ext
take a look at a popular application and discuss how we might architect the user interface to JS 4, Part 3 Sep 19
create a solid foundation.
Ext Designer 1.2 Overview
Code Organization Aug 4
Any ideas?
Application architecture is as much
If you have any ideas to
about providing structure and
improve this article, please
consistency as it is about actual classes let us know
and framework code. Building a good
architecture unlocks a number of
important benefits:
Every application works the same
way so you only have to learn it
once
It’s easy to share code between
apps because they all work the
same way
You can use Ext JS build tools to
create optimized versions of your
applications for production use
In Ext JS 4, we have defined
conventions that you should consider
following when building your
applications — most notably a unified
directory structure. This simple structure
places all classes into the app folder,
which in turn contains sub-folders to
www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-1/ 1/7

2. namespace your models, views, controllers and stores.
While Ext JS 4 offers best practices on how to structure your application, there’s room to
modify our suggested conventions for naming your files and classes. For example, you might
decide that in your project you want to add a suffix to your controllers with “Controller,” e.g.
“Users” becomes “UsersController.” In this case, remember to always add a suffix to both the
controller file and class. The important thing is that you define these conventions before you
start writing your application and consistently follow them. Finally, while you can call your
classes whatever you want, we strongly suggest following our convention for the names and
structure of folders (controller, model, store, view). This will ensure that you get an optimized
build using our SDK Tools beta.
Striking a Balance
Views
Splitting up the application’s UI into views is a good place to start. Often, you are provided
with wireframes and UI mockups created by designers. Imagine we are asked to rebuild the
(very attractive) Pandora application using Ext JS, and are given the following mockup by our
UI Designer.
What we want to achieve is a balance between the views being too granular and too generic.
Let’s start by seeing what happens if we divide our UI into too many views.
www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-1/ 2/7

3. Splitting up the UI into too many small views will make it difficult to manage, reference and
control the views in our controllers. Also, since every view will be in its own file, creating too
many views might make it hard to locate the view file where a piece of the UI or view logic is
defined.
On the other hand, we don’t want our views to be too generic because it will impact our
flexibility to change things.
In this scenario, each one of our views has been overly simplified. When several parts of a
view require custom view-logic, the view class will end up having too many responsibilities,
resulting in the view class becoming harder to maintain. In addition, when the designers
change their mind about the arrangement of the UI, we will end up having to refactor our view
definition and view logic; which can get tedious.
The right balance is achieved when we can easily rearrange the views on the page without
www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-1/ 3/7

4. having to refactor them every time. For example, we want to make the Ad a separate view,
so we can easily move it around or even remove it later.
In this version, we’ve separated our UI by the roles of each view. Once you have a general
idea of the views that will make up your UI, you can still tweak the granularity when you’re
actually implementing them. Sometimes you may find that two views should really become
one, or a view is too generic and should be split into multiple views, but it helps to start out
with a good base. I think we’ve done that here.
Models
Now that we have the basic structure of our views in place, it’s time to look at the models. By
looking at the types of dynamic data in our UI, we can get an idea of the different models
needed for our application.
We’ve decided to use only two models — Song and Station. We could have defined two
www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-1/ 4/7

5. more models called Artist and Album. However, just as with views, we don’t want to be too
granular when defining our models. In this case, we don’t have to separate artist and album
information because the app doesn’t allow the user to select a specific song by a given
artist. Instead, the data is organized by station, the song is the center point, and the artist and
album are properties of the song. That means we’re able to combine the song, artist and
album data into one model. This greatly simplifies the data side of our app. It also simplifies
the API that we have to implement on the server-side because we don’t have to load
individual artists or albums. To summarize, for this example, we’ll only have two models —
Song and Station.
Stores
Now that we’ve thought about the models our application will use, lets do the same for stores.
Figuring out the different stores you need is often relatively easy. A good strategy is to
determine all the data bound components on the page. In this case, we have a list with all of
the user’s favorite stations, a scroller with the recently played songs, and a search field that
will display search results. Each of these views will need to be bound to stores.
Controllers
There are several ways you can distribute the application’s responsibilities across your
application’s controllers. Let’s start by thinking about the different controllers we need in this
example.
www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-1/ 5/7

6. Here we have two basic controllers — a SongController and a StationController. Ext JS 4
allows you to have one controller that can control several views at the same time. Our
StationController will handle the logic for both creating new stations as well as loading the
user’s favorite stations into the StationsList view. The SongController will take care of
managing the SongInfo view and RecentSong store as well as the user’s actions of liking,
disliking, pausing and skipping songs. Controllers can interact with each other by firing and
listening for application events. While we could have created additional Controllers, one for
managing playback and another for searching stations, I think we’ve found a good
separation of responsibilities.
Measure Twice , Cut Once
I hope that sharing our thoughts on the importance of planning your application architecture
prior to writing code was helpful. We find that talking through the details of the application
helps you to build a much more flexible and maintainable architecture.
Continue on to Architecting Your App in Ext JS 4, Part 2
Share this post: Leave a reply
Written by Tommy Maintz
Tommy Maintz is the original lead of Sencha Touch. With extensive knowledge of Object Oriented JavaScript
and mobile browser idiosyncracies, he pushes the boundaries of what is possible within mobile browsers.
Tommy brings a unique view point and an ambitious philosophy to creating engaging user interfaces. His
attention to detail drives his desire to make the perfect framework for developers to enjoy.
Follow Tommy on Twitter
0 Comments
K Ramesh Babu 12 months ago
What is the motivation behind the ‘stores’ concept? Should we call this
paradigm MVCS rather than MVC?
Ali 11 months ago
Isn’t a store part of the model? At least, that’s how MVC sees it. Also don’t
understand the reason for a clientside “controller”. Should that contain all
www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-1/ 6/7

7. clientside handlers, and then redirect to the serverside MVC controller?
Would like to see this more detailed..
Ed Spencer Sencha Employee 11 months ago
Stores are really nothing more than a glorified array of Model *instances*.
They’re mostly used in our data-bound components like grids. We could
just use an array but the Store gives all kinds of benefits like sorting,
filtering and firing events whenever Model instances are added, removed or
updated, which makes acting on those changes much easier
Commenting is not available in this channel entry.
Find Sencha developers at SenchaDevs © 2012 Sencha Inc. All rights
reserved.
www.sencha.com/learn/architecting-your-app-in-ext-js-4-part-1/ 7/7