Extjs5.1中的新特性

Ext JS 5.0.1 is a maintenance release that addresses many bugs and limitations discovered by our community while testing Ext JS 5.0.0. We believe this update significantly strengthens the Ext JS 5 branch and we’re excited to hear your feedback. If you feel there are pieces missing from this guide, please let us know in the Ext JS 5 forums.

Let’s discuss a few of these improvements.

Accessibility

Ext JS 4.2.2 introduced the “ext-aria” package to provide improved support for accessibility, as described in the WAI-ARIA 1.0 standard. While this was an important step in creating accessible applications, we learned a lot from the feedback we received from our testing partners and early adopters. Ext JS 5.0.1 incorporates much of that feedback to provide a better solution moving forward.

Ext JS 5.0.1 re-introduces the concept of “ext-aria”, in addition to many other exciting improvements. Further, we have migrated support for focus and keyboard navigation from “ext-aria” to the framework’s core.

Focus

Ext JS 5.0.1 contains an improved strategy for the internal handling of focus. This internalization better aligns with accessibility standards. Core components, including buttons, tabs, form fields, and grids, now provide a clear, visual indication of focus. This is a key requirement for accessible applications. Users can modify several SASS variables and mixin parameters to gain more control over these new visual aspects.

Keyboard Navigation

Ext JS previously relied on Ext.FocusManager to assist in managing focus. While this class remains, it is no longer the recommended approach. It’s important to note that Ext.FocusManager has been deprecated and its future existence should not be relied upon. In its place, we have added a “focusable” property to components. This property is used to manage the tabIndex DOM attribute. Any component, with this property set to true, will be able to receive focus by clicking or via the keyboard input.

When these focusable components are placed in certain containers (such as toolbars), the container provides arrow key navigation and manages which item will receive the focus on entry into the container.

For more details regarding accessibility, focus, and keyboard navigation improvements, see the Accessibility Guide.

ViewModels

We have addressed a number of bugs related to viewModels, but there are some noteworthy improvements related to binding as well.

Selection Binding

Developers may now use “selection” as a bindable property on certain components. These components include ComboBox, Grids, Trees, Breadcrumbs, etc. Using the selection binding keeps the component selections in sync.

For details, see the Kitchen Sink example.

Model & Field Validation

One key improvement with form fields is that two-way bindings now check that the value is valid before updating their bound properties. The form fields can now acquire the Model’s validators and include them in their own validation.

As of Ext JS 5.0.1, invalid values will never be put back into your records.

Data

Ext.data has also been an area of a few key fixes and improvements in Ext JS 5.0.1.

TreeStore vs Node Events

The TreeStore class was refactored in Ext JS 5.0.0 to extend Ext.data.Store. With this change, TreeStore would relay events from the root node (Ext.data.NodeInterface). Unfortunately, certain node events collided with store events, which created problems for listeners. One such example was the “remove” event.

Ext JS 5.0.1 modifies the TreeStore strategy by prefixing all node events with “node” before firing them as TreeStore events. This means that the node’s “remove” event is now fired from the TreeStore as “noderemove”.

We always strive to avoid such changes in a maintenance release. However, this was a crucial change necessary to resolve the issue without breaking node listeners and/or store listeners.

Associations

Ext JS 5.0.0 introduced a lot of exciting new changes in terms of associations. However, one limitation that we discovered was that if you created a new record and then dropped that record, there was no cleanup logic to handle potential child records. This could create a situation where a session would generate create or update operations for these child records. These operations could not be processed by the server since the parent record was not saved.

Ext JS 5.0.1 offers reference fields that declare parent/child ownership between Models. These reference fields are then consulted when dropping records. When you indicate this type of association, dropped records will automatically handle deleting their child records.

For example:

 

 

Ext.define('App.model.Order', {

    extend: 'Ext.data.Model',

    // ...

});

 

Ext.define('App.model.OrderItem', {

    extend: 'Ext.data.Model',

 

    fields: [{

        name: 'orderId',

 

        // Indicates that the referenced Model (Order) owns these

        // records:

        reference: { parent: 'Order' }

    }]

});

 

 

In this way, when an Order it dropped (marked for deletion), its child OrderItems will likewise be dropped:

 

 

order.drop();

 

 

Further, setting parent references to null (for example, by removing it from the parent’s association store) schedules that record for cleanup.

 

 

order.orderItems().removeAt(0); // removed orderItem is dropped

 

order.orderItems().getAt(0).setOrder(null); // also drops this item

 

 

The server is still ultimately responsible for a full cascade delete, but the above handling ensures that the client will never reference dropped records in save operations.

Responsive Configs

The new responsiveConfig provided by Ext.mixin.Responsive and Ext.plugin.Responsive provide flexibility for cleanly managing dynamic conditions.

The new responsiveFormulas allow you to add properties for responsiveConfig rules. For example, your main controller could do something like this to publish new properties:

 

 

Ext.define('MyApp.view.main.Main', {

    extend: 'Ext.container.Container',

 

    mixins: [

      'Ext.mixin.Responsive'

    ],

 

    responsiveFormulas: {

        small: 'width < 600',

        medium: 'width >= 600 && width < 800',

        large: 'width >= 800',

 

        tuesday: function (context) {

            return (new Date()).getDay() === 2;

        }

    }

});

 

 

These responsiveForumulas then produce these new values, which can be used in any of your responsiveConfig’s. This can help streamline your application’s responsiveConfigs, as well as give you a single place to maintain these kinds of choices.

Charts

The “sencha-charts” package also benefits from several improvements (such as some stock marker sprites like arrows, diamonds, etc). We’ve also modified our build process to include a packaged version of the sencha-charts package so that users aren’t required to use Sencha Cmd. However, the most significant of these that we documented and exposed custom theme creation.

Chart Themes

Ext JS 5.0.0 shipped charts with several built-in themes that you could select for your charts. However, building custom themes was not a documented process. With this release, we have opened up this ability so that you can make your own color palettes and much more.

A theme for charts is a class derived from Ext.chart.theme.Base and given an alias that starts with:

 

 

"chart.theme."

 

 

A basic theme could be as simple as this:

 

 

Ext.define('App.chart.theme.Awesome', {

    extend: 'Ext.chart.theme.Base',

    alias: 'chart.theme.awesome',

 

    singleton: true,

 

    config: {

      baseColor: '#4d7fe6'

    }

});

 

 

From here, you can add any number of other configs to style your series, axes and markers. To see all the options check out Ext.chart.theme.Base reference for the available configs.

To use the above you would simply set the “theme” config on your charts:

 

 

theme: 'awesome'

 

 

Sencha Cmd

Last but not least, Sencha Cmd 5.0.1 expands upon options available in app.json. This gives you more fine-grained control to configure your application without having to delve into the build scripts.

Output

To give you a peek at the most useful of these new controls, let’s look at the “output” object. A common requirement for some environments is to maintain the “markup” file in a folder other than where the Sencha application resides. For example:

 

 

foo.php

foo/

    app.json

    app.js

 

 

The difference with this model is that the markup file (“foo.php” above, but it could be anything) is in a parent folder. In previous releases, this required setting several build properties. In Sencha Cmd 5.0.1 we can now do this in app.json:

 

 

{

    ...

    "output": {

        "page": {

            "path": "../foo.php",

            "enable": false

        }

    }

}

 

 

That single setting ensures that all paths will be calculated relative to the parent folder while also disabling the build step that rewrites the markup file. The “output” object can control many other aspects of your build’s output such from enabling compiler optimizations to tuning the microloader.

To learn more about these new available options, please open app.json and review the robust commenting.

Packager

Cordova and PhoneGap are now much more flexible and easier to use with the new “packager” property. This new setting allows your build to specify its packager (either “cordova” or “phonegap”) directly in app.json. Combined with the “builds” object, we can make an application that builds for web, iOS and Android. Further, we can specify local Cordova builds for Android and use the PhoneGap Cloud Build for iOS since iOS requires a Mac.

For example:

 

 

{

    ...

    "builds": {

        "web": {

            "default": true  // picked by "sencha app build" 

        },

        "ios": {

            "packager": "phonegap",

            "phonegap": {

                "config": {

            "platform": "ios",

                    "remote": true  // use PhoneGap Build

                }

            }

        },

        "android": {

            "packager": "phonegap"  // Any OS can build Android

        "phonegap": {

            "config": {

                "platform": "android" // use Local Phonegap

            }

        }

        }

    }

}

 

 

As before we can run a build like so:

 

 

sencha app build

 

 

The above will use the “web” build definition. But now we can also do these:

 

 

sencha app build ios

sencha app build android

 

 

Of course, you will need to have Cordova and PhoneGap installed and you will also need to configure your PhoneGap Build account. Other than formalities, you can see how this property cleans up the build process. Using this approach also frees you up to add “testing” to any of these builds and get uncompressed JavaScript code for debugging.