Home Web Development Ext JS Application Development Blueprints

Ext JS Application Development Blueprints

books-svg-icon Book
eBook $39.99
Print $48.99
Subscription $15.99
$10 p/m for first 3 months. $15.99 p/m after that. Cancel Anytime!
What do you get with a Packt Subscription?
This book & 7000+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with a Packt Subscription?
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with eBook + Subscription?
Download this book in EPUB and PDF formats, plus a monthly download credit
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with a Packt Subscription?
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with eBook?
Download this book in EPUB and PDF formats
Access this title in our online reader
DRM FREE - Read whenever, wherever and however you want
Online reader with customised display settings for better reading experience
What do you get with video?
Download this video in MP4 format
Access this title in our online reader
DRM FREE - Watch whenever, wherever and however you want
Online reader with customised display settings for better learning experience
What do you get with video?
Stream this video
Access this title in our online reader
DRM FREE - Watch whenever, wherever and however you want
Online reader with customised display settings for better learning experience
What do you get with Audiobook?
Download a zip folder consisting of audio files (in MP3 Format) along with supplementary PDF
What do you get with Exam Trainer?
Flashcards, Mock exams, Exam Tips, Practice Questions
Access these resources with our interactive certification platform
Mobile compatible-Practice whenever, wherever, however you want
BUY NOW $10 p/m for first 3 months. $15.99 p/m after that. Cancel Anytime!
eBook $39.99
Print $48.99
Subscription $15.99
What do you get with a Packt Subscription?
This book & 7000+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with a Packt Subscription?
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with eBook + Subscription?
Download this book in EPUB and PDF formats, plus a monthly download credit
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with a Packt Subscription?
This book & 6500+ ebooks & video courses on 1000+ technologies
60+ curated reading lists for various learning paths
50+ new titles added every month on new and emerging tech
Early Access to eBooks as they are being written
Personalised content suggestions
Customised display settings for better reading experience
50+ new titles added every month on new and emerging tech
Playlists, Notes and Bookmarks to easily manage your learning
Mobile App with offline access
What do you get with eBook?
Download this book in EPUB and PDF formats
Access this title in our online reader
DRM FREE - Read whenever, wherever and however you want
Online reader with customised display settings for better reading experience
What do you get with video?
Download this video in MP4 format
Access this title in our online reader
DRM FREE - Watch whenever, wherever and however you want
Online reader with customised display settings for better learning experience
What do you get with video?
Stream this video
Access this title in our online reader
DRM FREE - Watch whenever, wherever and however you want
Online reader with customised display settings for better learning experience
What do you get with Audiobook?
Download a zip folder consisting of audio files (in MP3 Format) along with supplementary PDF
What do you get with Exam Trainer?
Flashcards, Mock exams, Exam Tips, Practice Questions
Access these resources with our interactive certification platform
Mobile compatible-Practice whenever, wherever, however you want
  1. Free Chapter
    Introduction
About this book
Publication date:
April 2015
Publisher
Packt
Pages
340
ISBN
9781784395308

 

Chapter 1. Introduction

Learning how to understand a single line of code, building that first "Hello World" script, and experiencing the thrill when it works as you expect are the small steps that draw us into the world of programming. This book is about the projects we can build in this world using Sencha's Ext JS 5 and how to ensure you're building on a strong foundation.

In this chapter, we're going to examine why strong application architecture is important from a theoretical and practical point of view. We'll introduce the rest of the book and answer the following questions:

  • What is application architecture?

  • How is it important?

  • How does Ext JS help with application design?

  • How will this book help your software architecture?

Let's start with talking about what we mean by software architecture and why it's important for a successful project.

 

Humble beginnings


As coders, many of us would have started our development career by writing scripts or code that we found helpful, which helped out with a hobby. That buzz, the insight that you can create something practical and useful, that's where the passion starts. It's from these hastily assembled first few lines on which many of us have built a career.

In those early days, we found ourselves writing code that spanned hundreds of lines, but with no regard for how it might look if we came back to it in six months. Would it be understandable? Can a feature be added without breaking something else? Also, what if we want to share it with a friend or on the Internet? Trying to work out the cause of a bug is going to rapidly become a nightmare.

In fact, the Internet is littered with such code. Why is this a problem? Let's say you got roped into building a simple shopping cart for a friend. You knew enough to get it working, but also enough to be dangerous. A shopping cart is responsible for taking payment for goods, and a single security hole could result in someone being out of pocket. Suddenly, your favor for a friend has become something that has caused them to lose face and money.

Fortunately, in my case, there were no drastic ramifications for my lack of development expertise as a newcomer to coding. I created a PHP script. This script generated a photo gallery for a website. It started off as a list of photos and expanded to include thumbnail generation, pagination, and an administration/upload facility. It was an example of traditionally bad PHP with HTML mixed in with logic code and spaghetti loops to try and make the thing work the way I wanted.

With time, the solution comes organically; we start to break our work into smaller chunks that make sense for the application. It will slowly become clear that there are sensible ways of working, which make life easier, as your codebase grows. In the photo gallery example, I could start to extract very simple aspects (such as headers, footers, and pagination links) in order to focus on the core functionality.

Of course, not everyone starts this way. Developing a hobby into a career is just one path by which the coding community develops its skillset. University or online courses, books, and forums contribute to our learning process. The important thing to bear in mind is that neither coder nor architect was born into the world knowing everything and it's okay, even essential, to admit when there's a gap in your knowledge. From a senior consultant to hobbyist hacker, we're going to try and fill some of these gaps, as you build larger and more complex applications.

Growing up

Rather than writing code that is for a hobby or side project, we're now writing applications that help run businesses. Someone is paying for this development time, and someone's livelihood is relying on it. As professional software developers, we need to adopt a professional mindset and skillset to match. Rather than coming up with an idea and sitting down to code it immediately, we need to carefully consider how our application is constructed. We need to ensure that it will work as expected when real-world users get their hands on it; this will provide a strong platform for future developers to build on.

As software developers, we can be responsible for tens of thousands of lines of code—and in many cases more—and may be working in a team comprising a range of other individuals. At this scale, badly designed applications can become unwieldy, unreliable, and difficult to test.

It's unwieldy because without a strong design, functionality is tacked on as it's required, building on an already shaky foundation; unreliable because this shaky foundation has cracks crawling with bugs, and difficult to test because the system's parts are so intertwined that each component doesn't have a clear set of responsibilities and capabilities.

This is the danger of taking an idea and running with it; you may be creating code that grows out of control like a weed in a garden. A design is the key because it allows you to be the gardener (carefully tending each facet of the system as it grows). We want to create a clear, positive structure for our team members to start from and build on.

The structure we want to create in an application should give us clear delineation between one component and another. Each part of the system should be responsible for itself and nothing more (a small part in a larger machine). The layers of our code (from data to presentation and all the wiring in between) should also be clear-cut because no one wants to see a template talking directly to a backend service.

This is a classic example of overlapping concern. In this presentation, code should never have to worry about fetching data, only how to present it. This, and many more such issues, can be easily avoided with a strong structure and application design that is implemented from the start.

The shoulders of giants

Many have gone on this journey of scalability before us. It's worth remembering that there are many formal metrics to help us determine whether our code is too complex. "Cyclomatic complexity" is one example, a technique that evaluates details (such as code cohesion and branching depth) and can be tied into automated systems that raise a warning when a threshold for complexity is crossed.

In reality though, such metrics are a method of firefighting complexity rather than planning to avoid it. By looking at ways in which we can structure our code for success, we can minimize the need for such automated checks.

The first stop must be object-orientated programming (OOP). By encouraging a piece of functionality to be encapsulated in a class, we immediately impose a sense of separation in our application. Just as splitting our multi-hundred-line script into separate chunks made sense, here we can formalize this approach by creating classes that take responsibility for a single piece of functionality.

With the photo gallery, the pagination is a great example of where concerns could overlap. My original implementation just had a lot of loops and conditional statements wrapped up with the HTML. Instead, we can have one class that does the logic of the pagination (for example, whether the "next" link is available) and another class responsible for generating the HTML based on this data.

In Ext JS 4, Sencha brought in a new class system that allows you to better create objects that encapsulate application functionality as well as a strong application framework. Ext JS 5 builds on this and adds some extra features to make the Ext JS application architecture ideal for everyone (from individual developers to large teams). The structured approach that it makes available allows you to scale a code base while keeping its foundations strong.

 

What is application architecture?


Most people have a general idea of the role of a traditional architect, creating precise diagrams to pass on to the builders and other craftsmen who will undertake construction. More than this, an architect needs to consider the materials used, the aesthetics of a building, and oversee the construction process.

In the world of software, the architect has a similar role: design and supervision. We need to invest in the role of an architect and ensure that we make it an end-to-end process that ensures we take responsibility of the quality of the final product. Design and supervision requires a comprehensive knowledge of the product requirements, the technologies involved, and the available resources. The architecture of a software program (our "raison d'etre") is multifaceted, from the quality of the up-front documentation that dictates how the project will be built, to the finesse of the end product, which users will love to work with.

Requirement analysis

A software project should never begin without a list of requirements from the customer, client, or other stakeholder. This is often in the form of a detailed specification document. Requirement analysis involves the architect understanding the problem that needs to be solved and applying what they've learned to the next stages of the process.

Here's a short example:

Users should be able to log in, log out, register, and request a new password. Login should be persistent across browser sessions.

The architect reads this and the developers (in turn) end up with the following code to handle user logins:

Ext.define('MyApp.SessionManager', {
    login: function(username, password) {
        User.login(username, password, {
            success: Ext.bind(this.loginSuccess, this)
        });
    },
    loginSuccess: function() {
        this.isLoggedIn = true;
    }
});

This should be familiar to a seasoned Ext JS developer: we use Ext.define to create a class called MyApp.SessionManager. The login method contains an invocation of a login method on the User class and triggers a callback if it succeeds. Using Ext.bind, we set the scope of the success callback to the SessionManager class and when it's called, we set the isLoggedIn value to true. Further code would then redirect the authenticated user to the rest of the application.

The problem is that the architect has not correctly processed the requirements. They have missed the second part (the part that mandates that logins should be persistent across sessions). In this code sample, we store the login state in memory. To support the requirements, we should use a cookie, localStorage, or some other storage mechanism to make the login available between browser sessions. What will this code look like? Let's tweak this class a little, change one method, and add a few more methods:

loginSuccess: function(userDetails) {
    this.setUser(userDetails);
},

isUserLoggedIn: function() {
    return window.localStorage.getItem('user') === null;
},

setUser: function(userDetails) {
    window.localStorage.setItem('user', Ext.encode(userDetails));
},

getUser: function() {
    return Ext.decode(window.localStorage.getItem('user'));
}

The replacement loginSuccess method passes off to setUser, which makes use of localStorage to persist user details across browser sessions. We also provide an additional isUserLoggedIn method to check localStorage for any user details and a getUser method to grab these details. Note the use of Ext.encode and Ext.decode to convert JavaScript objects to strings that can be inserted into localStorage.

This is a more realistic implementation of this functionality that needs to be better specified at a higher level. Without translating this requirement from the client's stipulations through to the developer's instructions, we'd be omitting an important part of the application's feature set.

Data design

As with much of the application architecture, it will be a collaborative effort between the architect, developers, database administrators, and other members of the technical team. Data design is the result of a discussion about the data you need to store, where it will be stored, and how this will be reflected in the stores and models in your Ext JS. Let's look at a theoretical requirement for an application:

After three failed login attempts, the user account will be locked for 30 minutes.

This means that we need to record the number of failed login attempts and the last login attempt in the User model or some other persistence method (such as a server-side database). Without it, we wouldn't be able to create the correct client-side logic and UI to support this requirement.

Code design

Perhaps, the bulk of an architect's work comes from structuring the application's code base. Depending on the size of the team, the architect may or may not be involved in writing the code itself, but they will have intimate knowledge of the application at a higher level (almost certainly at the class level and in important situations at the method level). In many cases, UML or other diagramming tools will be used to provide a way of recording and sharing the design, as shown in the following diagram:

A UML-like diagram showing the models in a theoretical music application

The Album class that comes from this would look like the following code:

// model/Artist.js
Ext.define('MyApp.model.Artist.', {
    extend: 'Ext.data.Model',

    fields: [
         { name: 'name', type: 'string' }
    ]
});

// model/Album.js
Ext.define('MyApp.model.Album', {
    extend: 'Ext.data.Model',
    
    fields: [
         { name: 'name', type: 'string' },
         { name: 'artist', reference: 'Artist' }
    ],
    getRunningTime: function() {
          return this.tracks().sum('lengthInMs');
    }
});

// model/Track.js
Ext.define('MyApp.model.Track.', {
    extend: 'Ext.data.Model',

    fields: [
         { name: 'title', type: 'string' },
         { name: 'lengthInMs', type: 'integer' },
         { name: 'album', reference: 'Album' }
    ]
});

We define fields with the reference config to set up a many-to-one relationship between artists and albums, and albums and tracks. The getRunningTime method, which was shown in the previous class diagram, is an example of an area that an architect might not get involved in (they can leave the implementation details of this method to a developer).

This is the key aspect of architecture that we'll be covering in this book.

Technology evaluation

In this book, we will discuss Ext JS 5, so our technology choice should be fairly straightforward! Nonetheless, it's important for an architect to evaluate all of the relevant parts of their technology stack to ensure that it supports the product requirements. Here are some technology questions that are still relevant in our situation:

  • Do we need to cater to various form factors (such as mobile and tablet)?

  • Do we need to support Internet Explorer 8?

  • Do we need to talk to a SOAP service?

All of these have potential ramifications that an architect must evaluate while planning a project.

Code standards and practices

In the same way that a building architect must make sure the design they create adheres to building code and safety regulations as well as ensuring the materials they use will create a pleasing finish, software architects must also take steps to guarantee the quality of the finished product.

Naming conventions, formatting guidelines, a process to deploy the application—all these contribute to having a professional workflow that makes it easy for the developers and project to succeed. The architect is the guiding hand, bringing the customer something that exceeds their expectations.

Documentation

There are many reasons why documenting the development process is a good idea. For example:

  • Transparency between team members

  • Providing a point of reference during development

  • Offering a comparison for post-project review

Having a single point of reference for the design documents helps in a large team and assists with bringing new team members up to speed. It's a very bad idea for the architect to hold all of their ideas in their head, and it's a very good idea for this knowledge to be shared, discussed, and recorded. Such documentation might come in a variety of forms:

  • Class diagrams

  • UI wireframes

  • User stories

  • Coding standards

  • Code documentation

Code documentation will often be automatically created as part of a build process, but an architect will be responsible for mandating this code to be documented and instituting a build step to generate it. Other forms will be part of a manual process and can involve the client, the development team, and the architect.

Note

These definitions are up for discussion! Wikipedia's software architecture page is extensive and offers multiple points of view at http://en.wikipedia.org/wiki/Software_architecture.

In the next few pages, we'll look at how software and software developers can find themselves in possession of an unwieldy code base, what makes it unwieldy, why it's a problem. We'll also look at the attributes that make for a well-architected software product.

 

Ext JS


Before version 4 of Ext JS, Sencha didn't try to impose any kind of structure on our applications. Components were split across multiple files, but other than this, we didn't have any guidance on how they should communicate or how they are pieced together to form an application. Ext JS began with version 1.0 on April 15, 2007 as a library of user interface widgets—buttons, trees, grids, and features (such as layouts) to help them all hang together, but not much more than this.

At the time, this didn't seem to matter much. The idea of a single page application written in JavaScript still felt like the technology of the future, and while it was starting to happen, it certainly wasn't as ordinary as it was in 2014. Augmenting existing web pages with slick Ajax-powered widgets was more than enough.

As time went on, with lots of widgets and dynamic parts of the website all needing to interact, the requirement for a formal mechanism for intercommunication became obvious. People were using Ext JS to build enterprise-level applications that specified high levels of availability and therefore rigorous testing regimes. Spaghetti code just wasn't going to cut it anymore.

The world that was

Let's take a look at a classic piece of example code from back in the days of Ext 3.4:

// View a working version at https://fiddle.sencha.com/#fiddle/90s

// Basic JSON sample data
var sampleData = { data: [
    { "firstName": "Jack", "surname": "Slocum" },
    { "firstName": "Shea", "surname": "Frederick" },
    { "firstName": "Colin", "surname": "Ramsay" },
    { "firstName": "Steve", "middle": "Cutter", "surname": "Blades" },
    { "firstName": "Nigel", "surname": "White" },
] };

// Create a store to hold our JSON data
var userStore = new Ext.data.JsonStore({
    data: sampleData,
    root: 'data',
    fields: ['firstName', 'middle', 'surname']
});

// Grid panel using the store, setting the columns to match the incoming data
var grid = new Ext.grid.GridPanel({
    store: userStore,
    colModel: new Ext.grid.ColumnModel({
        defaults: {
            width: 120,
            sortable: true
        },
        columns: [
            { header: 'First Name', dataIndex: 'firstName' },
            { header: 'Middle', dataIndex: 'middle' },
            { header: 'Surname', dataIndex: 'surname' }
        ]
    }),
    viewConfig: {
        forceFit: true
    },
    width: 600,
    height: 300,
    frame: true
});

// Event handler to do something when the user clicks a row
grid.on('rowclick', function(g, idx) {
    Ext.Msg.alert('Alert', 'You clicked on the row at index ' + idx);
});

// Render the grid to the viewport
grid.render(document.body);

This block of code should be familiar to the reader as something that generates a populated grid:

When a row on the grid is clicked on, an alert box appears showing the index of the target row. This is all well and good. It represents a fairly typical example of what you'd have seen in the Ext JS documentation at the time of Ext JS 3.4.

So, what's the problem? The problem is that this code does everything. It sets up our data store, drawing JSON from either a remote or local source. It creates the grid itself along with its many configuration options. It sets up event handling code to pop up the alert box. And after all that's been done, it finally renders the grid to the screen.

Within a simple piece of code like this, the problem is less pronounced. Although, when more functionality is added, such as paging or a detail window popping up with further information about a record and tying all of this into a larger application with server-side interaction, multiple screens, and so on, then things start to get tricky.This is the type of issue that Sencha tried to resolve by introducing defined architectural practices in Ext JS 4. Rather than putting everything together and mixing all these different concerns, the idea was that they could be pulled apart into more logical, concise, and distinct objects.

State of the art

The model-view-controller (MVC) pattern was the choice of the new wave of web developers. Ruby on Rails had already popularized MVC and many other major frameworks had brought their own ideas to the table.

Tip

While MVC has often been used in web development over recent years, it's used elsewhere in software development and, indeed, was originally developed for desktop GUI coding. Learning about MVC as a general concept is outside our scope, but there's plenty of information and examples on the Web.

Ext JS 4.0 was released on April 26, 2011, over 4 years after v1.0, and many developers were already comfortable with using the MVC pattern in their server-side apps. Frameworks (such as Backbone.js) had slowly begun to give developers the tools to use such architectural patterns in their client-side code. Ext JS 4 needed to do the same and it delivered.

Mostly very cool

Prior to version 4, Ext JS had stores and records (the "model" in MVC). It had components or widgets (the "view" in MVC). The architectural issue was twofold; how did models and views talk to each other? How did we avoid making our views bloated with logic code?

One answer was to introduce the controller concept. This allowed us to create a layer of glue to create stores, hook them up to components, and use events to manage communication between all of these parts of the application.

In version 5 of Ext JS, a couple of extra features fully answered our architectural questions with ViewControllers and ViewModels. ViewControllers allow us to separate out logic code in our views into a distinct class, ensuring that both the view and ViewController can focus on their own set of responsibilities.

Supporting cast

As well as building classes into the Ext JS framework to help us build complicated applications, Sencha has also provided a number of supplementary tools that assist with the development process. In particular, Sencha Cmd is a powerful command-line tool that introduces some indispensable facilities.

From the beginning, Sencha Cmd can help by generating the directory structure of your application with a best practice layout, specifically created to help with the new Ext JS 5 cross-device support. You can add new models, controllers, and so on, all from the command line.

As you're developing, Sencha Cmd can help you by compiling theme files, slicing and dicing images, and running a development web server to run your code locally. Also, during testing and deployment, it can package your code into an optimized bundle to give your users the minimum amount of code to download in their browser.

Sencha Cmd is a great example of a product that is growing up. It represents a key piece of your development infrastructure and a fantastic complement to the Ext JS framework itself.

 

Getting ready


We know about the issues we'd like to address and how we're going to learn to do so. So, now let's look at some of the non-architectural aspects of an application that you might want to think about even before starting to put pen to paper on the design. While everything we've discussed so far talks about the overarching method to shape the development of an application, the other parts of the puzzle can often be just as important.

The specification

How do you design an application without knowing what it is you're designing? This is what a specification provides. A document or series of documents that describe in exacting detail how the features that make up your software should behave. It's a continuing mistake in the software business that we don't collect the requirements of our users and clients before we start writing code. In the same way that it's irresponsible to build an application without architecting it correctly, it's irresponsible to build an application without being as certain as possible that you're creating the correct thing for a paying customer. What sort of issues can a specification avoid? Some of them are as follows:

  • Missed deadlines

  • Cost overruns

  • Developer stress

  • Customer dissatisfaction

This reads as a fairly generic list of things we don't want during our project.

More importantly for the purposes of this book, a specification allows you to have all of the information needed to create your application design. It doesn't necessarily mean our design will be right, but without a specification, you can guarantee the design will be wrong.

A good match

Part of creating both a specification and a design is understanding the customer requirements; understanding the "problem domain" that represents their business. It's really hard to write a piece of computer software for a shipping business unless you understand at least a little bit about shipping, for example the way they calculate rates in relation to cargo weight and the distance it's travelling.

In regard to Ext JS, we may be working with an external SOAP API that provides these shipping rates. Well, Ext JS supports working with SOAP (with a Sencha Complete license), but if it didn't, this would probably affect our design—we'd have to write more code to talk to the SOAP API—and therefore our timings.

We're writing a content management system, but it needs to be very closely tied with the customer's branding due to agreements with third parties. Will the Ext JS theming system allow us to incorporate the extensive customization needed for the project?

We started working on a sales portal for a new client when the Finance Director reveals that all his work outside the office is done on an iPad mini. We now have to work backwards to incorporate touchscreen support. If we'd have consulted all of the stakeholders at the right time, we'd have saved weeks of work.

These examples are somewhat contrived, but serve to highlight that application design is not only about software, but also a fusion of consulting the people involved, evaluating your resources, understanding the problem domain, and creating a software architecture. These requirements don't exist in isolation.

How we work

Consider bringing a new developer or tester in your team. How quickly can they get up and running with the latest build of your code? How can they track down the code change that resulted in a bug they're working on and then find the developer responsible for the bug? Is there a particular way in which automated tests should be created and new code should be written?

These are all highly important questions when creating a successful application because they reduce the barrier between creating and improving the existing code base and keeping the quality of the resulting code high. Joel Spolsky, of Microsoft and Fog Creek fame, wrote a blog article back in 2000 that is still highly relevant today. Titled The Joel Test: 12 Steps to Better Code, it asked twelve questions of development houses based on Joel's extensive experience working with a variety of coding teams and projects (from Microsoft Excel to Fog Creek's own Trello). The whole article's well worth a read, but we're going to take a fresh look at it with regards to Ext JS development.

 

In safe hands


Joel's first question, "Do you use source control?"

Step one when a new developer arrives is where is your code kept? We're long past shared network drives and manually copying the code of other developers on your team, so you should be using some form of source control. This is definitely a situation in which something is better than nothing, so we won't specifically discuss the alternatives, but in my case, I'm using Git, which is created as the source control system for the Linux kernel and is now extremely popular in software development.

Each member of your team can now grab code from each other, roll back their mistakes, track changes, and find the origin of bugs. However, a source repository is not just a giant hole in which everyone's files is up. There are some that are unique to each developer (such as configuration files for an IDE), and there are some that are automatically generated by a build process or other script. With Git, we'd use a .gitignore file to exclude several items that simply create a message of your repository and commits:

# sample gitignore for extjs5
# The build directory can be recreated by developers using Sencha Cmd – it should be excluded from the repo
build/
# Changes every time a build is run
bootstrap.js
bootstrap.css

# Temporary files created when compiling .scss files
.sass-cache/

# Some team members may use Sencha architect – exclude so they keep their custom settings
.architect

# It's possible to create reusable packages using Sencha Cmd but depending on your preference you might want to exclude this directory. Packages are discussed in chapter 3.
packages/

There will be a lot more than this in a .gitignore file if your Ext JS application shares a directory with any server-side code. Most large projects will have a heavily customized .gitignore file. Moreover, not all source control systems will have a similar feature and setting it up at the start of the project will keep your application history neat and tidy.

If you build it, they will come

Joel's second question, "Can you make a build in one step?"

We mentioned earlier that it needs to be easy for developers and testers to build a final version of your application from the raw source code. This could be the process that compresses your CSS and JavaScript so that your users can download it more quickly. The key is that you want to be testing your work against the same final build as your users to avoid bugs creeping through.

In Ext JS 5, we can use the Sencha Cmd to create development, testing, and production builds and it can even be used to create a packaged version of your application for deployment on touch devices. In doing so, it gives a unified mechanism for your whole team to work from the same build with a single command, making Joel very happy. This also ties into his third question, "Do you make daily builds?" With the tools we've described so far, an automated build system can grab the latest and greatest code from source control, build it using the Sencha Cmd, and deploy it to a testing or beta server for evaluation.

Managing your time

Joel's fourth question, "Do you have an up-to-date schedule?" and his fifth question, "Do you have a spec?"

Of course, neither of these is specific to Ext JS applications, but they're tightly related to the theme of this book. We've discussed having a specification that informs your application design, but it's an up-to-date schedule that goes hand in hand. By designing your application correctly, you are dividing it into sections that can be scheduled by yourself, your team, or your management.

A single controller with its associated views and the required models could be scheduled to take a month to complete, so an app designed to have three controllers could take three months. Joel's sixth question's a little bit more specific than this though, he asks for an up-to-date schedule. This means examining your work to ensure you're meeting your schedule and adjusting accordingly. It also means learning from a slipping schedule and realizing that your design may have been flawed in some ways. A more complex view with lots of interaction will clearly take more time than a simple view, so it's not as straightforward as our "one month per controller" suggestion.

You can buy fashion, but you can't buy style

The rest of Joel's questions are more general, so we'll skip them and talk about another important facet of setting up your development process: style. Not what your developers are wearing, but the way in which they write code. There are two things to consider here, the ones related to JavaScript and the ones specific to Ext JS.

The developers of Twitter Bootstrap caused upset in 2012 by opting not to use semicolons at the end of lines of JavaScript and combining that with some slightly obtuse syntax. Refer to https://github.com/twbs/bootstrap/issues/3057.

In truth, it doesn't matter too much whether you use semicolons or not in most circumstances due to JavaScript's automatic semicolon insertion. Refer to http://ecma262-5.com/ELS5_Section_7.htm#Section_7.9.

The more important point is that whatever you do, do it consistently and make sure everyone working on your application is doing it too. Not doing this will have severe consequences for the maintainability of your application as it's developed (imagine having files with two or three different styles of commenting, string quoting, and conditional statements).

Ext JS itself has a couple of conventions that will make your life much easier if you adhere to them. When a controller requires a store, you can do it like this:

Ext.define('MyApp.controller.MyController', {
    extend: 'Ext.app.Controller',

    requires: [
        'MyApp.store.Albums'
    ],

    getAlbumsStore: function() {
        return this.getStore('Albums');
    }
});

This is equivalent to:

Ext.define('MyApp.controller.MyController', {
    extend: 'Ext.app.Controller',

    stores: ['Albums']
});

As the Store class was defined as 'MyApp.store.Albums', we can refer to it with the 'Albums' shortcut. Likewise, controllers should always have "controller" as the middle part of the class name, "model" for models, and "view" for views.

This is partially covered in the naming conventions segment of the Ext JS 5 Core Concepts guide. What isn't explicitly mentioned is the way that these shortcuts are pervasive across Ext JS and how they can make your code much clearer.

 

Summary


Although a lot of this book discusses the bigger picture of designing an application, there are many different criteria for developing a successful product. Attention must be paid to the smaller things that we've already mentioned (such as semicolon style or naming conventions) in order to not only provide a solid foundation for your code, but also to ensure everyone who is working with it feels invested and on the same page. You're not only painting a picture of a well-architected application, but you're also building an intricate machine with hundreds of moving parts. All of them need to be well oiled for your project to succeed.

In the next chapter, we'll start to talk about the theory of application structure and discuss design patterns that will help shape our code base. We'll frame this in the context of Ext JS and show how it provides a strong set of features that build on these patterns and enable us to begin setting up the architecture for a robust application.

Latest Reviews (1 reviews total)
Exatamente o que eu estava procurando.
Ext JS Application Development Blueprints
Unlock this book and the full library FREE for 7 days
Start now