Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Ext JS Application Development Blueprints
Ext JS Application Development Blueprints

Ext JS Application Development Blueprints: Develop robust and maintainable projects that exceed client expectations using Ext JS

eBook
€20.98 €29.99
Paperback
€36.99
Subscription
Free Trial
Renews at €18.99p/m

What do you get with Print?

Product feature icon Instant access to your digital eBook copy whilst your Print order is Shipped
Product feature icon Paperback book shipped to your preferred address
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
OR
Modal Close icon
Payment Processing...
tick Completed

Shipping Address

Billing Address

Shipping Methods
Table of content icon View table of contents Preview book icon Preview Book

Ext JS Application Development Blueprints

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:

Code design

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:

The world that was

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.

Left arrow icon Right arrow icon

Description

If you are a developer who has knowledge of Ext JS but would like to expand it to encompass the bigger picture of application development, then this book is ideal for you.

Who is this book for?

If you are a developer who has knowledge of Ext JS but would like to expand it to encompass the bigger picture of application development, then this book is ideal for you.

What you will learn

  • Simplify your code by understanding how to use Ext JS view models and data binding
  • Build basic applications with the MVVM architecture
  • Architect advanced Ext JS applications based on a set of requirements
  • Understand code reuse techniques in Ext JS by identifying code that can be extracted to library classes
  • Learn advanced Ext JS topics such as responsive design and sessions in Ext JS
  • Work with testing, debugging, and performance tools to ensure that the final product is robust
  • Discover an integrated approach to building software, in which the design, tools, and code are equally important to a successful final product
Estimated delivery fee Deliver to Hungary

Premium delivery 7 - 10 business days

€25.95
(Includes tracking information)

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : Apr 24, 2015
Length: 340 pages
Edition : 1st
Language : English
ISBN-13 : 9781784395308
Vendor :
Netscape
Languages :
Tools :

What do you get with Print?

Product feature icon Instant access to your digital eBook copy whilst your Print order is Shipped
Product feature icon Paperback book shipped to your preferred address
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
OR
Modal Close icon
Payment Processing...
tick Completed

Shipping Address

Billing Address

Shipping Methods
Estimated delivery fee Deliver to Hungary

Premium delivery 7 - 10 business days

€25.95
(Includes tracking information)

Product Details

Publication date : Apr 24, 2015
Length: 340 pages
Edition : 1st
Language : English
ISBN-13 : 9781784395308
Vendor :
Netscape
Languages :
Tools :

Packt Subscriptions

See our plans and pricing
Modal Close icon
€18.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
€189.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just €5 each
Feature tick icon Exclusive print discounts
€264.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just €5 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total 120.97
Learning Ext JS_Fourth Edition
€41.99
Ext JS Application Development Blueprints
€36.99
Mastering ExtJS - Second Edition
€41.99
Total 120.97 Stars icon

Table of Contents

12 Chapters
1. Introduction Chevron down icon Chevron up icon
2. MVC and MVVM Chevron down icon Chevron up icon
3. Application Structure Chevron down icon Chevron up icon
4. Sencha Cmd Chevron down icon Chevron up icon
5. Practical – a CMS Application Chevron down icon Chevron up icon
6. Practical – Monitoring Dashboard Chevron down icon Chevron up icon
7. Practical – an E-mail Client Chevron down icon Chevron up icon
8. Practical – Questionnaire Component Chevron down icon Chevron up icon
9. A Shopping Application Chevron down icon Chevron up icon
10. Debugging and Performance Chevron down icon Chevron up icon
11. Application Testing Chevron down icon Chevron up icon
Index Chevron down icon Chevron up icon

Customer reviews

Rating distribution
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
(1 Ratings)
5 star 0%
4 star 100%
3 star 0%
2 star 0%
1 star 0%
DJ K Jun 25, 2015
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
As is mentioned in the forward this book is not for beginners. If you are relatively new to working with Ext JS this book is a good way to become more familiar with concepts like MVC and MVVM. Since the book references Ext JS 5 it is still relevant as of my writing of this review. There are some nice examples of small applications using techniques that can be used in many different apps.
Amazon Verified review Amazon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

What is the delivery time and cost of print book? Chevron down icon Chevron up icon

Shipping Details

USA:

'

Economy: Delivery to most addresses in the US within 10-15 business days

Premium: Trackable Delivery to most addresses in the US within 3-8 business days

UK:

Economy: Delivery to most addresses in the U.K. within 7-9 business days.
Shipments are not trackable

Premium: Trackable delivery to most addresses in the U.K. within 3-4 business days!
Add one extra business day for deliveries to Northern Ireland and Scottish Highlands and islands

EU:

Premium: Trackable delivery to most EU destinations within 4-9 business days.

Australia:

Economy: Can deliver to P. O. Boxes and private residences.
Trackable service with delivery to addresses in Australia only.
Delivery time ranges from 7-9 business days for VIC and 8-10 business days for Interstate metro
Delivery time is up to 15 business days for remote areas of WA, NT & QLD.

Premium: Delivery to addresses in Australia only
Trackable delivery to most P. O. Boxes and private residences in Australia within 4-5 days based on the distance to a destination following dispatch.

India:

Premium: Delivery to most Indian addresses within 5-6 business days

Rest of the World:

Premium: Countries in the American continent: Trackable delivery to most countries within 4-7 business days

Asia:

Premium: Delivery to most Asian addresses within 5-9 business days

Disclaimer:
All orders received before 5 PM U.K time would start printing from the next business day. So the estimated delivery times start from the next day as well. Orders received after 5 PM U.K time (in our internal systems) on a business day or anytime on the weekend will begin printing the second to next business day. For example, an order placed at 11 AM today will begin printing tomorrow, whereas an order placed at 9 PM tonight will begin printing the day after tomorrow.


Unfortunately, due to several restrictions, we are unable to ship to the following countries:

  1. Afghanistan
  2. American Samoa
  3. Belarus
  4. Brunei Darussalam
  5. Central African Republic
  6. The Democratic Republic of Congo
  7. Eritrea
  8. Guinea-bissau
  9. Iran
  10. Lebanon
  11. Libiya Arab Jamahriya
  12. Somalia
  13. Sudan
  14. Russian Federation
  15. Syrian Arab Republic
  16. Ukraine
  17. Venezuela
What is custom duty/charge? Chevron down icon Chevron up icon

Customs duty are charges levied on goods when they cross international borders. It is a tax that is imposed on imported goods. These duties are charged by special authorities and bodies created by local governments and are meant to protect local industries, economies, and businesses.

Do I have to pay customs charges for the print book order? Chevron down icon Chevron up icon

The orders shipped to the countries that are listed under EU27 will not bear custom charges. They are paid by Packt as part of the order.

List of EU27 countries: www.gov.uk/eu-eea:

A custom duty or localized taxes may be applicable on the shipment and would be charged by the recipient country outside of the EU27 which should be paid by the customer and these duties are not included in the shipping charges been charged on the order.

How do I know my custom duty charges? Chevron down icon Chevron up icon

The amount of duty payable varies greatly depending on the imported goods, the country of origin and several other factors like the total invoice amount or dimensions like weight, and other such criteria applicable in your country.

For example:

  • If you live in Mexico, and the declared value of your ordered items is over $ 50, for you to receive a package, you will have to pay additional import tax of 19% which will be $ 9.50 to the courier service.
  • Whereas if you live in Turkey, and the declared value of your ordered items is over € 22, for you to receive a package, you will have to pay additional import tax of 18% which will be € 3.96 to the courier service.
How can I cancel my order? Chevron down icon Chevron up icon

Cancellation Policy for Published Printed Books:

You can cancel any order within 1 hour of placing the order. Simply contact customercare@packt.com with your order details or payment transaction id. If your order has already started the shipment process, we will do our best to stop it. However, if it is already on the way to you then when you receive it, you can contact us at customercare@packt.com using the returns and refund process.

Please understand that Packt Publishing cannot provide refunds or cancel any order except for the cases described in our Return Policy (i.e. Packt Publishing agrees to replace your printed book because it arrives damaged or material defect in book), Packt Publishing will not accept returns.

What is your returns and refunds policy? Chevron down icon Chevron up icon

Return Policy:

We want you to be happy with your purchase from Packtpub.com. We will not hassle you with returning print books to us. If the print book you receive from us is incorrect, damaged, doesn't work or is unacceptably late, please contact Customer Relations Team on customercare@packt.com with the order number and issue details as explained below:

  1. If you ordered (eBook, Video or Print Book) incorrectly or accidentally, please contact Customer Relations Team on customercare@packt.com within one hour of placing the order and we will replace/refund you the item cost.
  2. Sadly, if your eBook or Video file is faulty or a fault occurs during the eBook or Video being made available to you, i.e. during download then you should contact Customer Relations Team within 14 days of purchase on customercare@packt.com who will be able to resolve this issue for you.
  3. You will have a choice of replacement or refund of the problem items.(damaged, defective or incorrect)
  4. Once Customer Care Team confirms that you will be refunded, you should receive the refund within 10 to 12 working days.
  5. If you are only requesting a refund of one book from a multiple order, then we will refund you the appropriate single item.
  6. Where the items were shipped under a free shipping offer, there will be no shipping costs to refund.

On the off chance your printed book arrives damaged, with book material defect, contact our Customer Relation Team on customercare@packt.com within 14 days of receipt of the book with appropriate evidence of damage and we will work with you to secure a replacement copy, if necessary. Please note that each printed book you order from us is individually made by Packt's professional book-printing partner which is on a print-on-demand basis.

What tax is charged? Chevron down icon Chevron up icon

Currently, no tax is charged on the purchase of any print book (subject to change based on the laws and regulations). A localized VAT fee is charged only to our European and UK customers on eBooks, Video and subscriptions that they buy. GST is charged to Indian customers for eBooks and video purchases.

What payment methods can I use? Chevron down icon Chevron up icon

You can pay with the following card types:

  1. Visa Debit
  2. Visa Credit
  3. MasterCard
  4. PayPal
What is the delivery time and cost of print books? Chevron down icon Chevron up icon

Shipping Details

USA:

'

Economy: Delivery to most addresses in the US within 10-15 business days

Premium: Trackable Delivery to most addresses in the US within 3-8 business days

UK:

Economy: Delivery to most addresses in the U.K. within 7-9 business days.
Shipments are not trackable

Premium: Trackable delivery to most addresses in the U.K. within 3-4 business days!
Add one extra business day for deliveries to Northern Ireland and Scottish Highlands and islands

EU:

Premium: Trackable delivery to most EU destinations within 4-9 business days.

Australia:

Economy: Can deliver to P. O. Boxes and private residences.
Trackable service with delivery to addresses in Australia only.
Delivery time ranges from 7-9 business days for VIC and 8-10 business days for Interstate metro
Delivery time is up to 15 business days for remote areas of WA, NT & QLD.

Premium: Delivery to addresses in Australia only
Trackable delivery to most P. O. Boxes and private residences in Australia within 4-5 days based on the distance to a destination following dispatch.

India:

Premium: Delivery to most Indian addresses within 5-6 business days

Rest of the World:

Premium: Countries in the American continent: Trackable delivery to most countries within 4-7 business days

Asia:

Premium: Delivery to most Asian addresses within 5-9 business days

Disclaimer:
All orders received before 5 PM U.K time would start printing from the next business day. So the estimated delivery times start from the next day as well. Orders received after 5 PM U.K time (in our internal systems) on a business day or anytime on the weekend will begin printing the second to next business day. For example, an order placed at 11 AM today will begin printing tomorrow, whereas an order placed at 9 PM tonight will begin printing the day after tomorrow.


Unfortunately, due to several restrictions, we are unable to ship to the following countries:

  1. Afghanistan
  2. American Samoa
  3. Belarus
  4. Brunei Darussalam
  5. Central African Republic
  6. The Democratic Republic of Congo
  7. Eritrea
  8. Guinea-bissau
  9. Iran
  10. Lebanon
  11. Libiya Arab Jamahriya
  12. Somalia
  13. Sudan
  14. Russian Federation
  15. Syrian Arab Republic
  16. Ukraine
  17. Venezuela