Many systems have a special format for passwords. Let's say we need the password to have at least one digit (0-9), one letter lowercase, one letter uppercase, one special character (@,#,$,%, and so on) and its length between 6 and 20 characters.

We can create a regular expression to validate that the password is being entered into the app. And to do this, we can create a custom VType to do the validation for us. To create a custom VType is simple. For our case, we can create a custom VType called customPass, as follows:

Ext.apply(Ext.form.field.VTypes, {
    customPass: function(val, field) {
        return /^((?=.*d)(?=.*[a-z])(?=.*[A-Z])(?=.*[@#$%]).{6,20})/.test(val);
    },
    customPassText: 'Not a valid password.  Length must be at least 6 characters and maximum of 20. Password must contain one digit, one letter lowercase, one letter uppercase, one special symbol @#$% and between 6 and 20 characters.'
});

The name of our custom VType is customPass, and we need to declare a function that will validate our regular expression. And customPassText is the message that will be displayed to the user just in case the incorrect password format is entered.

The preceding code can be added anywhere in the code, inside the init function of a Controller, inside the launch function of app.js, or even in a separate JavaScript file (recommended) where you can put all your custom Vtypes.

Create a new file named CustomVTypes.js under the app directory. Add the preceding code to this file. Now, we need this file to be loaded with our application as well. But hold your instincts to manually include this JavaScript file in the index.html file. We are going to follow best practices!

Locate the following code around line 110 of the app.json file inside the masteringextjs folder:

"js": [
    {
        "path": "app.js",
        "bundle": true
    }
],

To make our CustomVTypes.js file automatically load with our application, we simply need to add the following highlighted code:

"js": [
    {
        "path": "app.js",
        "bundle": true
    },
    {
        "path": "app/CustomVTypes.js",
        "includeInBundle": true
    }
], 

The includeInBundle configuration tells Sencha Cmd that this file needs to be added to the final .js file that is generated.

Only one file can have the bundle: true configuration. This means that it is the main file of the application.

Now, let's apply the custom VType to our code. Add the following code to the password field:

vtype: 'customPass',
msgTarget: 'side'

Also, change the message target for the password field. As the error message is quite long, it will not look nice with the message target under. This will be the result after we apply the custom vType:

To execute the code we have created so far, we need to make a few changes in the Application.js file.

First, we need to declare the views we are using (only one in this case), as follows:

views: [
    'login.Login'
],

And the last change is inside the launch function. In the preceding chapter, we left a console.log message where we needed to instantiate our initial view; now we only need to replace the console.log message with the Login instance (#1):

me.splashscreen.next().fadeOut({
    duration: 1000,
    remove:true,
    listeners: {
       afteranimate: function(el, startTime, eOpts ){
            Ext.widget('login-dialog'), //#1
        }
    }
});

Now that Application.js is OK, and we can execute what we have implemented so far!

A quick overview about Ext JS dynamic class loading

Dynamic class loading was introduced in Ext JS 4. It provides an integrated dependency management capability, and it is very useful, especially when working on the development (local) environment (it also plays an important role in the final production build). This capability is also one of the reasons why option 5 for instantiating classes in Ext JS (using the keyword new) became deprecated and not a best practice.

What does dynamic loading mean? It means that we do not need to load all Ext JS SDK classes prior to load our application. For example, for the Login window, we are using the Window, Form, and TextField classes from the Ext JS SDK. To execute our application, we do not need the source code of the grid, tree, and charts. Do you agree?

Still on the Login window example, when our application is loaded, Ext JS will read that the 'login.Login' view needs to be loaded. As all the application source code is inside the app folder, and the views are inside the app/view folder, the Ext JS loader will expect to find the app/view/login/Login.js file, and inside this file it expects to find the 'Packt.view.login.Login' class definition (this is why it is very important to follow the naming conventions we introduced earlier). The Ext JS loader will then see that this class inherits from the Ext.window.Window class, and if this class was not loaded yet, it is going to figure out all its dependencies (from the extend and requires declarations—we will discuss requires in a bit) and load them until we have all the source code required to execute the application loaded (and it will do this recursively until all code is loaded).

For example, when you try to execute the application, open the Chrome Developer Tools (Ctrl + Shift + I or Command + Shift + I) or Firebug for Firefox (enable all panels) and open the Network tab. We will be able to see all files that were loaded for our application, as follows:

We know that 5MB is scary for only a Login screen, but we will solve this issue when we do the production build later on this book. We do not need to worry about it for now.

What will happen later when we do the production build is that Ext JS will know which classes from the SDK need to be included in the final JavaScript file, will concatenate everything into a single file, and will also obfuscate it. If you try to open any of the files listed in the preceding screenshot, you will be able to read the source code (and it will be pretty and indented as the development source code should be).

In the preceding chapter, we covered an introduction of the MVC architecture in Ext JS. Let's refresh our memory quickly of how MVC works:

The Model represents the information that is being used by the application. The View is what the user will see on the screen—the components. In each interaction of the user with the application, the components will fire events. The Controller is where we are going to handle the events and execute any logic that is needed; the Controller is going to manage the information (Model) and also manage the View (and the interaction between the View and Model).

In Ext JS 5, Sencha introduced this new pattern called Model View ViewModel (MVVM), which is shown in the following diagram:

What happens in the MVVM is that using this pattern, it is much easier to control the View and the Model if they are bound. For example, consider that we have a data grid where we list some contacts. When we select a contact and click on the Edit button, we want the application to open a pop up about the title that will be the name of the contact and the pop up will also have a form that will display the contact details for editing. If we use the default MVC pattern, we will need to control the way the View (data grid, pop up, and form) interacts with the Model (contact information). The MVVM (which is based on the MVC) introduces a new abstraction entity that is the ViewModel. The ViewModel mediates changes between the View and the associated Model.

However, with this new pattern and new ViewModel abstraction, Sencha also introduced an abstraction for the controller, which is bound to the View, called the ViewController. The ViewController is very similar to the traditional controller of the MVC pattern, which is as follows:

However, as we learned in Chapter 2, Getting Started, the controllers of the MVC pattern are created in the scope of the application, and they are unique instances (meaning a single instance of each controller of the application). As long as the application is running, the controllers are also alive.

The ViewModel and ViewController are part of the component (we learned about component in Chapter 1, Sencha Ext JS Overview). As long as the View is alive, they are also alive. When the View is destroyed, they also get destroyed. This means that we can save some memory (if we do not have many instances of the same View at once).

Do not worry if you do not understand all these concepts 100 percent right now. We will learn how to use them and how they work with some examples, and throughout this book we will use these different options of architecture so that we can learn how each one works, and maybe you can choose the one you like the most or the one that is going to fit your project best.

Let's stop to think a little bit. Logging in is performed once during the application's lifetime. There are three things we can do in the application: log in to start using it, use its capabilities, or log out (because we clicked on the logout button or the session expired). Once we have logged in, we are in, and that is it.

In the previous topic we learned that the ViewModel and the ViewController are destroyed once the View is destroyed. So, instead of having a controller for the login alive during the application's lifetime, we can have a controller that will be alive only during the time that the login View is alive. For this reason, for the Login screen, we will use the ViewController.

The first step is creating the JavaScript file. Inside app/view/login, we will create the LoginController.js file. Inside this file, we will implement the following code, which is only a base of the ViewController class we are going to implement:

Ext.define('Packt.view.login.LoginController', { // #1
    extend: 'Ext.app.ViewController',            // #2
    alias: 'controller.login',                   // #3 

    onTextFieldSpecialKey: function(field, e, options){ }, // #4

    onTextFieldKeyPress: function(field, e, options){ }, // #5

    onButtonClickCancel: function(button, e, options){ }, // #6

    onButtonClickSubmit: function(button, e, options){ }, // #7

    doLogin: function() { }, // #8

    onLoginFailure: function(form, action) { }, // #9

    onLoginSuccess: function(form, action) { } // #10
});

As usual, on the first line of the class, we have its name (#1). Following the same formula we used for the view/login/Login.js, we will have Packt (app namespace) + view (name of the package) + login (name of the sub package) + LoginController (name of the file), resulting in Packt.view.login.LoginController.

The ViewController classes need to extend from Ext.app.ViewController (#2) so that we will always use this parent class for our ViewController.

We also need to give an alias to this ViewController (#3). Aliases for ViewControllers start with 'controller', followed by the alias we want to assign (remember that the alias is always in lowercase).

For #4–#10, we have the signature of some methods we will implement until the end of this chapter. We will go through each of them later.

controller: 'login',

requires: [
    'Packt.view.login.LoginController'
],

Our next step now is to start listening to the Login window events. First, we are going to listen to the Submit and Cancel buttons.

As we are using a ViewController class and not a Controller (MVC), we need to add listeners inside the Login class. First, let's do it for the Cancel button, as follows:

xtype: 'button',
iconCls: 'fa fa-times fa-lg',
text: 'Cancel',
listeners: {    click: 'onButtonClickCancel'}

This code means that when a user clicks on the Cancel button, the onButtonClickCancel method from the Login ViewController class will be executed. So let's implement this method! Back to the LoginController class, we already know that this is the method we are going to implement:

onButtonClickCancel: function(button, e, options){}

But how do we know which are the parameters the method can receive? We can find the answer to this question in the documentation. If we take a look at the click event in the documentation (Button class), this is what we will find:

This is exactly what we declared. For all the other event listeners, we will go to the docs and see which are the parameters the event accepts, and then list them as parameters in our code. This is also a very good practice. We should always list out all the arguments from the docs even if we are only interested in the first one (or even none). This way, we always know that we have the full collection of the parameters, and this can come in very handy when we are doing maintenance on the application.

Note that we also want to listen to the Submit button click. The onButtonClickSubmit method has the same signature as the onButtonClickCancel method. Let's go ahead and also add the listener to the Submit button, as follows:

xtype: 'button',
formBind: true,
iconCls: 'fa fa-sign-in fa-lg',
text: 'Submit',
listeners: {    click: 'onButtonClickSubmit'}

Let's do a quick test to see if everything is working as expected so far:

onButtonClickCancel: function(button, e, options){
    console.log('login cancel'), // #1
},

onButtonClickSubmit: function(button, e, options){
    console.log('login submit'),  // #2          
},

For now, we are only going to output a message on the console to make sure our code is working. So, we are going to output 'login submit' (#2) if the user clicks on the Submit button, and 'login cancel' (#1) if the user clicks on the Cancel button.

Let's go ahead and try it. Click on the Cancel button and then on the Submit button. This should be the output:

xtype: 'form',
reference: 'form',

onButtonClickCancel: function(button, e, options){
    this.lookupReference('form').reset();
},

Submit Button Listener implementation

Now we need to implement the onButtonClickSubmit method. Inside this method, we want to program the logic to send the User and Password values to the server so that the user can be authenticated.

We can implement two programming logics inside this method: the first one is to use the submit method that is provided by the Form Basic class, and the second one is to use an Ajax call to submit the values to the server. Either way, we will achieve what we want to do. For this example, we will use the default form submit call.

These are the steps we need to perform in this method:

• Get the Login form reference
• Get the Login window reference (so we can close it once the user has been authenticated)
• Send Login information to the server
• Handle the server response, as follows:
  • If the user is authenticated, display application
  • If not, display error message

We already know how to get the form reference. This is how onButtonClickSubmit will look:

onButtonClickSubmit: function(button, e, options){
    var me = this;
    if (me.lookupReference('form').isValid()){ // #1
        me.doLogin();              // #2
    }
},

So first, before doing anything, we will make sure the user has entered all the required information (user name and valid password (#1)). If everything is OK, then we call a helper method that will handle the authentication (#2), as follows:

doLogin: function() {
    var me = this,
        form = me.lookupReference('form'),

    form.submit({
        clientValidation: true,        // #3
        url: 'php/security/login.php', // #4
        scope: me,         // #5
        success: 'onLoginSuccess',     // #6
        failure: 'onLoginFailure'      // #7
    });
},

First, just to make sure the data we are trying to submit is valid (we will call this doLogin method from another method as well, so to be sure we are sending valid data to server is never too much!), we set the clientValidation configuration as true to validate the information one more time (#3). Then we have the url that is going to be called (#4). The success (#6) and failure (#7) callbacks were declared as separate functions, which belong to the ViewController class, and that is why the scope is the ViewController class (#5).

Tip

We could implement the success and failure methods inside the submit call as well (as showed by the example in the documentation http://docs.sencha.com/extjs/5.0.0/apidocs/#!/api/Ext.form.Basic-method-submit). But we do not know how much code we will need to handle the authentication. Working with scoped callbacks is better because our code stays organized, with better readability.

If we try to run this code, the application will send the request to the server, but we will get an error as response because we do not have the login.php page implemented yet. That's OK because we are interested in other details right now.

With Firebug or Chrome Developer Tools enabled, open the Network tab and filter by the XHR requests. Make sure to enter a username and password (any valid value so we can click on the Submit button). This will be the output:

Note that the user and password are being sent as form data. This information is useful to handle the information on the server side (which in our case is the PHP code).

Tip

Whenever you have questions or you have no idea how you are going to handle the information sent by Ext JS to the server, open the debug tool of your browser and inspect the call. This helps a lot and also helps you to learn more about how Ext JS works when communicating with the server.

The first step is to create the file that is going to be responsible for connecting to the database. We are going to reuse this file in almost every PHP page that we are going to develop.

Create a new folder named php under the project's root folder, and under php, create a new folder named db. Then, create a new file named db.php:

<?php 
$server = "127.0.0.1";
$user = "root";
$pass = "root";
$dbName = "sakila";

$mysqli = new mysqli($server, $user, $pass, $dbName);

/* check connection */
if ($mysqli->connect_errno) {
    printf("Connect failed: %s
", mysqli_connect_error());
    exit();
}
?>

The connection is pretty straightforward. We simply need to inform the server (which is going to be localhost), the databases username and password, and also the database name that we want to connect to. And at last, we can check whether the connection was done successfully or any error occurred.

Finally, we can create the login.php file under the php/security folder. So let's start implementing it, as follows:

require("../db/db.php"); // #1
require("PassHash.php"); // #2

session_start();         // #3

$userName = $_POST['user']; // #4
$pass = $_POST['password']; // #5

$userName = stripslashes($userName); // #6
$pass = stripslashes($pass);         // #7

$userName = $mysqli->real_escape_string($userName); // #8
$sql = "SELECT * FROM USER WHERE userName='$userName'"; // #9

First, we need to require the db.php file to connect to the database (#1). We are also going to require the PassHash.php file (#2). This file contains the check_password method, which will compare the password entered by the user with the one that is stored in the database (hashed).

Then, we start a session (#3)—we are going to store the username on the session later.

The next step is to retrieve the user and password values sent by the form submit method from Ext JS (#4 and #5).

The stripslashes function removes the backslashes from the given string (#6 and #7). For example, if the user value is "Loiane's", the return of stripslashes will be "Loiane's".

Then, we prepare the $username variables for the SQL statement using the function real_escape_string (#8), which escapes special characters in a string for use in a SQL statement.

Next, we prepare the SQL query that is going to be executed (#9). It is a simple SELECT statement that is going to return a result matching the given username.

Let's continue with the next part of the code:

if ($resultDb = $mysqli->query($sql)) { //#10

  $count = $resultDb->num_rows; //#11

  if($count==1){ //#12

        $record = $resultDb->fetch_assoc(); //#13

         //#14  
        if (PassHash::check_password($record['password'],$pass)){
            $_SESSION['authenticated'] = "yes"; //#15
            $_SESSION['username'] = $userName; //#16

            $result['success'] = true; //#17
            $result['msg'] = 'User authenticated!'; //#18
        } else{
            $result['success'] = false; //#19
            $result['msg'] = 'Incorrect password.'; //#20
        }
  } else {
    $result['success'] = false; //#21
    $result['msg'] = 'Incorrect user or password.'; //#22
  }
  $resultDb->close(); //#23
}

Next, we need to execute the SQL query, and we are going to store the result set in the resultDb variable (#10). Then, we are going to store data according to whether the result set returned any rows within the result set (#11).

Now comes the most important part of the code. We are going to verify whether the result set returned any rows. As we passed the username, the number of rows returned within the result set must be exactly 1. So, if the number of rows is equal to 1 (#12), we need to see whether the hashed password stored in the database matches the password entered by the user, but first, we need to retrieve this information from the record that was fetched from the database (#13).

The PassHash class is responsible for hashing the password, making it a little bit more secure to save the hashed password in the database (instead of the plain password), for decrypting the hashed password from the database ($record['password']), and for comparing to the password the user entered in the login page (#14).

If the password entered by the user and the decrypted hash password from the database match, it means the user can be authenticated. We are going to store the username of the authenticated user (#16) in the Session and also the information that the user is authenticated (#15).

We also need to prepare the result that we are going to return to Ext JS. We are going to send back two pieces of information: the first one is about whether the user is authenticated (#17)—in this case "true"—and we can also send back a message (#18).

If the password entered by the user and the one from the database do not match, then we also need to return something to Ext JS. The success is going to be false (#19), and we are going to return a message so that we can display to the user (#20).

If the username does not exist in the database (number of rows returned within the result set is different from 1), we are also going to send back a message to Ext JS saying the username or password informed by the user is incorrect (#22). Therefore, the success information will be false (#21).

Then, we need to close the result set (#23).

Now, the third and last part of the code of login.php:

$mysqli->close(); // #23

echo json_encode($result); // #24

We need to close the database connection (#23), and we are going to encode the result that we are going to send back to Ext JS in the JSON format (#24).

And now, the login.php code is complete. We cannot forget to add <?php before the preceding code.

Note that in (#5), (#6), and (#7) we are using the same error alert pop up, so code is repeated. Alert errors like this are used in different places of the application. As we are going to handle more Ajax requests and form submits in other screens of the application as well, the code in (#3) and (#4) will be repeated as well. For this reason, we can create a Util class that will encapsulate this code and provide us with the means to reuse it. Besides the reuse pro, it is also good to establish a pattern to be followed by the application, such as working out the JSON format that the server needs to return to Ext JS. This will make the application more organized, and it is also good when working in a team (usually each developer has their own pattern that they like to follow, and this way, we follow the same pattern for the same application, and it will not look as though it was implemented by different developers).

So let's go ahead and create our first Util class. We will name it Packt.util.Util. For this reason, we are going to create a new file named Util.js, and we are also going to create a new folder named util under the app folder, as follows:

Ext.define('Packt.util.Util', {

    statics : { //#1

        decodeJSON : function (text) { //#2
            var result = Ext.JSON.decode(text, true);
            if (!result){
                result = {};
                result.success = false;
                result.msg = text;
            }

            return result;
        },

        showErrorMsg: function (text) { //#3
            Ext.Msg.show({
                title:'Error!',
                msg: text,
                icon: Ext.Msg.ERROR,
                buttons: Ext.Msg.OK
            });
        }
    }
});

All methods will be inside the statics declaration (#1). As we learned in Chapter 1, Sencha Ext JS Overview, we can simply call Packt.util.Util.decodeJSON for example, without needing to instantiate the Packt.util.Util class. The decodeJSON method (#2) contains the code to handle the JSON decoding, and the method showErrorMsg (#3) contains the code to display an error pop up alert with the content passed in the text parameter.

Let's rewrite the onLoginFailure method by using the Util class, as follows:

onLoginFailure: function(form, action) {

    var result = Packt.util.Util.decodeJSON(action.response.responseText);

    switch (action.failureType) {
        case Ext.form.action.Action.CLIENT_INVALID:
            Packt.util.Util.showErrorMsg('Form fields may not be submitted with invalid values'),
            break;
        case Ext.form.action.Action.CONNECT_FAILURE:
       Packt.util.Util.showErrorMsg(action.response.responseText);
            break;
        case Ext.form.action.Action.SERVER_INVALID:
            Packt.util.Util.showErrorMsg(result.msg);
    }
}, 

Instead of 36 lines of code, now we have only 15, and the readability is better as well! In case we need to maintain this code, we can make the changes in the Util class, and the changes will be applied everywhere in the code that the class is being used! Best practices make our code really cool!

One last detail: we need to add the Packt.util.Util class in the requires declaration of the ViewController class as well:

requires: [
    'Packt.util.Util'
],

This is because of the dynamic loading we discussed earlier in this chapter. If we try to execute the preceding code without having the Util class loaded, we can get an error.