Top Support Tips

` using the `autoEl` config along with `cls` or `glyph`:

	Ext.create({
               xtype: 'image',
               autoEl: 'div',
               cls: 'x-fa fa-star',
	       //glyph: 'xf005@FontAwesome',
               alt: 'star',
               style: {
                        fontSize: '36px',
                        lineHeight: '36px'
               },
               height: 36,
               width: 36
         });

Note: For the `image` config, you’ll use `cls` instead of `iconCls`.

When Not Using the Triton Theme

If you’re not using the Triton theme, but still want to use the Font Awesome icons in your components, you can include the Font Awesome package in your Sencha Cmd-generated application. To do this, edit the `{appRoot}/app.json` file’s requires array as seen below:

	"requires": [
               "font-awesome"
        ],

You can then set the `iconCls` config on components directly as you would be able to when using the Triton theme.

Pictos Icons

You may also require the Pictos icon font set available from the SDK by requiring it in the `app.json` file as well:

	"requires": [
               "font-pictos"
        ],

Once required, you can use the following syntax for `iconCls` configs in order to use
icons from the Pictos library.

        // pictos-{iconName} is used to set a named icon from the Pictos icon set
        iconCls: 'pictos pictos-home'

For a map of available Pictos icons, see the Sencha Font Packages guide.

See our Theming Guide for more information on the Triton theme and the included font icons.

Another Option for Saving Association Data

by Joel Watson

When using associations in your Ext JS 5 application, there are a number of ways you can approach saving associated data. Whether you prefer to save each individual model instance separately, create a custom Ext.data.writer.Writer implementation, or use Ext.data.Session to create batches, Ext JS gives you great flexibility to work with your data in a way that best suits your application’s needs.

However, there are a few new additions in Ext JS 5 for Ext.data.writer.Writer that give you yet another option: allDataOptions and partialDataOptions.

These configurations allow you to define the options that will be passed to the getData() method of Ext.data.Model when the model’s data is being prepared to be sent to the server. allDataOptions is used for phantom (new) records (or when writeAllFields:true), while partialDataOptions is used for all others (or when writeAllFields:false).

So how does this help us with association data?

Let’s say we have two entities, User and Address:

Ext.define('User', {
    extend: 'Ext.data.Model',
    fields: ['firstName', 'lastName', 'age', {
        name: 'addressId',
        reference: 'Address',
        unique: true
    }],
    ...
});

Ext.define('Address', {
    extend: 'Ext.data.Model',
    fields: ['street', 'city', 'state', 'postalCode']
});

In this example, User has a one-to-one association with Address, so whenever we save a User (whether creating a new User or saving changes to an existing one), we would like to also send along any associated Address data in the same request.

In Ext JS 4, one way we could approach this would be to create a custom Ext.data.writer.Writer that expands getRecordData() to call Ext.data.Model.getAssociatedData() and add the association data to the request data. While this still works just fine in Ext JS 5, we can leverage allDataOptions and partialDataOptions to accomplish the same thing, but save a few lines of code:

Ext.define('User', {
    extend: 'Ext.data.Model',
    fields: [...],
    proxy: {
        type: 'ajax',
        url: 'user.json’,
        writer: {
            type: 'json',
            allDataOptions: {
                persist: true,
                associated: true
            },
            partialDataOptions: {
                changes: false, 
                critical: true,
                associated: true
            }
        }
    }
});

In our allDataOptions configuration, we have specified the options that we’d like to use during the process of preparing our newly-created User model’s data to be sent to the server:

• persist: true -> Only send persistent fields (this is set to true by default)
• associated: true -> Include association data

And the same principle applies for partialDataOptions, which will be used when preparing an existing User model’s data to be sent to the server:

• changes: true -> Only include modified fields (default)
• critical: true -> Always include “critical” fields, regardless of change (default)
• associated: true -> Include association data

Of course, you can tweak these configurations based on your application’s needs. However, with these in place, we should now see that when we create or update a User within our application, the request to the server will also include any association data. Nice!

For more information, please see this Fiddle example of creating and updating User and Address models.

Using Model Ids in Ext JS 5

by Joel Watson

In Ext JS 5, a fairly significant change was introduced regarding id generation. In Ext JS 4, the default id generator did not automatically generate values for the idProperty. So, take a simple example User model:

Ext.define('Fiddle.model.User', {
    extend: 'Ext.data.Model',
    fields: ['firstName', 'lastName', 'age'],
    proxy: {
        type: 'rest',
        url: 'user.json'
    }
});
// create a new User
var user = new Fiddle.model.User({
    firstName: 'John',
    lastName: 'Doe',
    age: 52
});
user.save();

When calling save(), the request to the server would look something like this:

{
    age: 52,
    firstName: "John",
    lastName: "Doe"
}

In Ext JS 5, however, the default id generator *does* generate a value for idProperty if none is provided. Taking the example above, this produces a slightly different result:

{
    id: "User-1",
    age: 52,
    firstName: "John",
    lastName: "Doe"
}

Notice how the “id” (which is the default idProperty) is now included in the request? In some instances, developers may have relied upon the Ext JS 4 behavior to determine how to handle incoming requests in their server-side code, in which case this change might introduce some conflicts for those building apps in Ext JS 5.

Fortunately, there are a number of options that you can use to work with (or slightly around) this change.

Id Generators

The first (and often best) option is to use one of the id generators included with Ext JS. For example, using the Ext.data.identifier.Negative id generator will produce a successive, negative number for the client-side id value. As most server-side integer-based ids are positive and sequential, the negative id produced by Ext JS is clearly recognizable as provisional, which should allow any server-side code to easily determine the difference between phantom and extant Ext JS model data.

Using our example from above, the negative identifier will produce a result like so:

{
    id: -1,
    age: 52,
    firstName: "John",
    lastName: "Doe"
}

Example: Using a negative identifier: https://fiddle.sencha.com/#fiddle/p03

Of course, if one of the included id generators does not suffice, you can always create your own by extending Ext.data.identifier.Generator.

clientIdProperty

If using an id generator is not feasible for your application’s requirements, another option is to use the clientIdProperty configuration which has been added to Ext.data.writer.Writer. Using this config, you can specify a custom name that will be used as the “key” for the idProperty value when creating a new record and sending its data to the server:

Ext.define('User', {
    extend: 'Ext.data.Model',
    fields: ['firstName', 'lastName', 'age'],
    proxy: {
        type: 'rest',
        url: 'user.json',
        writer: {
            type: 'json',
            clientIdProperty: 'userId'
        }
    }
})

When we save() the User instance, the data sent to the server will now take this form:

{
    "userId": "User-1",
    "firstName": "John",
    "lastName": "Doe",
    "age": 52
}

For existing server-side code that depended upon the absence of the “id” property to identify a new record, this approach maintains the status quo and doesn’t require a modification of the logic.

Example: Using clientIdProperty: https://fiddle.sencha.com/#fiddle/p02

transform()

A final option would be to specify a custom transform method on your proxy’s writer. transform() takes two arguments–”data” and “request”–and expects only that you return the data object that should be sent to the server:

writer: {
    type: 'json',
    transform: function(data, request) {
        // do any data transformations here
        // ...
        // return the data object that should be sent to server
        return data;
    }
}

Using transform(), you can do any processing of the data that is necessary (for example, removing the “id” property) prior to the request being sent to the server. Of the 3 options, this provides the most control over the form and content of the data that is sent to the server. However, it also introduces the most risk for data errors, so it should be used carefully.

Example: Using transform(): https://fiddle.sencha.com/#fiddle/p05

For more information about changes and improvements to the data model in Ext JS 5, please see the Ext JS 5 Upgrade Guide.