Setup
Many classes have shortcut names used when creating (instantiating) a class with a
configuration object. The shortcut name is referred to as an alias (or xtype if the
class extends Ext.Component). The alias/xtype is listed next to the class name of
applicable classes for quick reference.
Framework classes or their members may be specified as private or protected. Else,
the class / member is public. Public, protected, and private are access
descriptors used to convey how and when the class or class member should be used.
Public classes and class members are available for use by any other class or application code and may be relied upon as a stable and persistent within major product versions. Public classes and members may safely be extended via a subclass.
Protected class members are stable public members intended to be used by the
owning class or its subclasses. Protected members may safely be extended via a subclass.
Private classes and class members are used internally by the framework and are not intended to be used by application developers. Private classes and members may change or be omitted from the framework at any time without notice and should not be relied upon in application logic.
static label next to the
method name. *See Static below.Below is an example class member that we can disect to show the syntax of a class member (the lookupComponent method as viewed from the Ext.button.Button class in this case).
Let's look at each part of the member row:
lookupComponent in this example)( item ) in this example)Ext.Component in this case). This may be omitted for methods that do not
return anything other than undefined or may display as multiple possible values
separated by a forward slash / signifying that what is returned may depend on the
results of the method call (i.e. a method may return a Component if a get method calls is
successful or false if unsuccessful which would be displayed as
Ext.Component/Boolean).PROTECTED in
this example - see the Flags section below)Ext.container.Container in this example). The source
class will be displayed as a blue link if the member originates from the current class
and gray if it is inherited from an ancestor or mixed-in class.view source in the example)item : Object in the example).undefined a "Returns" section
will note the type of class or object returned and a description (Ext.Component in the
example)Available since 3.4.0 - not pictured in
the example) just after the member descriptionDefaults to: false)The API documentation uses a number of flags to further commnicate the class member's function and intent. The label may be represented by a text label, an abbreviation, or an icon.
classInstance.method1().method2().etc();false is returned from
an event handler- Indicates a framework class
- A singleton framework class. *See the singleton flag for more information
- A component-type framework class (any class within the Ext JS framework that extends Ext.Component)
- Indicates that the class, member, or guide is new in the currently viewed version
- Indicates a class member of type config
- Indicates a class member of type property
- Indicates a class member of type
method
- Indicates a class member of type event
- Indicates a class member of type
theme variable
- Indicates a class member of type
theme mixin
- Indicates that the class, member, or guide is new in the currently viewed version
Just below the class name on an API doc page is a row of buttons corresponding to the types of members owned by the current class. Each button shows a count of members by type (this count is updated as filters are applied). Clicking the button will navigate you to that member section. Hovering over the member-type button will reveal a popup menu of all members of that type for quick navigation.
Getting and setter methods that correlate to a class config option will show up in the methods section as well as in the configs section of both the API doc and the member-type menus just beneath the config they work with. The getter and setter method documentation will be found in the config row for easy reference.
Your page history is kept in localstorage and displayed (using the available real estate) just below the top title bar. By default, the only search results shown are the pages matching the product / version you're currently viewing. You can expand what is displayed by clicking on the button on the right-hand side of the history bar and choosing the "All" radio option. This will show all recent pages in the history bar for all products / versions.
Within the history config menu you will also see a listing of your recent page visits. The results are filtered by the "Current Product / Version" and "All" radio options. Clicking on the button will clear the history bar as well as the history kept in local storage.
If "All" is selected in the history config menu the checkbox option for "Show product details in the history bar" will be enabled. When checked, the product/version for each historic page will show alongside the page name in the history bar. Hovering the cursor over the page names in the history bar will also show the product/version as a tooltip.
Both API docs and guides can be searched for using the search field at the top of the page.
On API doc pages there is also a filter input field that filters the member rows using the filter string. In addition to filtering by string you can filter the class members by access level, inheritance, and read only. This is done using the checkboxes at the top of the page.
The checkbox at the bottom of the API class navigation tree filters the class list to include or exclude private classes.
Clicking on an empty search field will show your last 10 searches for quick navigation.
Each API doc page (with the exception of Javascript primitives pages) has a menu view of metadata relating to that class. This metadata view will have one or more of the following:
Ext.button.Button class has an alternate class name of Ext.Button). Alternate class
names are commonly maintained for backward compatibility.Runnable examples (Fiddles) are expanded on a page by default. You can collapse and expand example code blocks individually using the arrow on the top-left of the code block. You can also toggle the collapse state of all examples using the toggle button on the top-right of the page. The toggle-all state will be remembered between page loads.
Class members are collapsed on a page by default. You can expand and collapse members using the arrow icon on the left of the member row or globally using the expand / collapse all toggle button top-right.
Viewing the docs on narrower screens or browsers will result in a view optimized for a smaller form factor. The primary differences between the desktop and "mobile" view are:
The class source can be viewed by clicking on the class name at the top of an API doc page. The source for class members can be viewed by clicking on the "view source" link on the right-hand side of the member row.
Getting started with Ext JS 6 and Sencha Cmd 6 couldn't be easier. With a single command, you'll have a fully functional "universal" starter application that can be run on a local web server.
A "universal" application contains a core set of stores, models, and controllers, while presenting two different sets of views by way of the two toolkits: Classic, and Modern.
The Classic toolkit contains the traditional pieces of the Ext JS codebase that supports legacy browsers, tablets, and touch screen laptops. The Modern toolkit contains a touch-friendly codebase that supports modern browsers, tablets, and phones.
Let's get started!
Open your terminal or console window and issue these commands:
sencha -sdk /path/to/extjs/framework generate app AppName path/to/app
cd /path/to/app
sencha app watch
Note: For the purposes of this walkthrough, AppName will be MyApp and path/to/app will be ./MyApp.
That's it. You've created an application and deployed a server. Now navigate to http://localhost:1841 or your native localhost. You can now view your newly generated Ext JS 6 application.
Sencha Cmd is now monitoring your application for changes. You will see "Waiting for changes...", which is an indication that your application is up to date. As you make changes and save files you will see other messages printing, but these will end shortly with another "Waiting for changes..." message. This cycle usually takes a few seconds, so be sure to allow enough time between file saves and hitting Reload in your browser.
Note: If sencha app watch fails to pick up your changes for any reason,
you can simply stop (CTRL + c) and restart app watch.
Note: _If you're curious about what the above steps entail, you may want to check out our Introduction to Sencha Cmd Guide._
As mentioned above, Universal applications are made up of three important areas:
app folder in your application's root.classic/src folder in your application's root.modern/src folder in your application's root.It should be noted that this small application illustrates a huge number of features in Ext JS. There is not enough space to discuss everything in-depth, so we will do a small overview for the pertinent bits. We'll make sure to point you to more in-depth information for each topic when possible.
Let's begin by evaluating the Main classic view found in MyApp/classic/src/view/main/.
The Main classic view will appear anytime someone is using a desktop browser or a tablet, unless otherwise specified in your build targets.
Using your favorite IDE or text editor, open MyApp/classic/src/view/main/Main.js. This is
the main entry point for our classic application. It's also the container
that houses our tabpanel and its four tabs. Additionally, you'll see that the first tab
includes our grid class.
Let's walk through tabs.
TabPanels can be used similarly to standard Panel for layout purposes, but they also have special support for containing child Components (items). These items are managed using a Card layout manager, and displayed as separate tabs.
Tabs typically default to horizontally residing at the top of your item content. However, in this application, we have gotten a little clever with the tabs.
You may notice that our tabs don't look like traditional tabs. That's because we've created a custom UI for them.
Every component in the Ext JS framework has a ui configuration that defaults
to default. This property can be changed to allow components in your
application to have different styles.
Most Ext JS components have SASS @mixin's that allow you to quickly generate new UIs. These include: Ext.panel.Panel, Ext.button.Button, Ext.Toolbar, Ext.window.Window, and many more.
Let's open our tabpanel's custom UI and take a look at what's being done. You can find your tabpanel UI definitions here:
`classic/sass/src/view/main/Main.scss`
As you can see, creating UIs is simple. Simply call the associated @mixin for the component for which you want to create a UI.
@include extjs-tab-panel-ui(
$ui: 'navigation'
);
All of the variables within the @mixin can be modified in any way you like.
You then attach the UI to your component like so:
ui: 'navigation',
We'll discuss styling your application with SASS in greater detail below.
You may have also noticed that we added the Responsive plugin
to the tabPanel and the tabConfig.
// TabPanel
responsiveConfig: {
tall: {
headerPosition: 'top'
},
wide: {
headerPosition: 'left'
}
},
// Tab Config
tabConfig: {
plugins: 'responsive',
responsiveConfig: {
wide: {
iconAlign: 'left',
textAlign: 'left'
},
tall: {
iconAlign: 'top',
textAlign: 'center',
width: 120
}
}
}
This plugin allows us to set rules that modify the tabpanel and tab text/glyph positions based on the width and height of the viewport. In this case, if you make the browser window less wide than tall, the tabpanel will move to the top of the screen and the tab text and glyphs will reposition.
If the viewport is wider than tall, the tabs will appear on the left and adjust the tab text/glyph positions appropriately.
You can read more about the responsive plugin and building your application for multiple environments here.
You may notice that there's no hard-coded data in tabs 2, 3, and 4. That's because we're binding data from a ViewModel.
Together, View Models and
Data Binding
allow you to do more with less code and write in a much more declarative style.
A View Model is a class that manages a data object. It then allows components interested in this data to bind to it and be notified when it changes. The ViewModel, like ViewController, is owned by the view that references it.
For the most part, any config that may be "set" with a setter method, can be bound to the data in the ViewModel. For
this example, we'll utilize setHtml() and setTitle().
Let's take a look at the following lines:
// View Model Declaration
viewModel: 'main',
// Binding to header's title
header: {
title: {
bind: {
text: '{name}'
},
flex: 0
}
},
// Binding to tab's HTML config
{
title: 'Users',
iconCls: 'fa-user',
bind: {
html: '{loremIpsum}'
}
}
You can see that data is bound from the universal ViewModel (app/view/main/MainModel.js)
to the tabs and app title. The data in the ViewModel is set statically, but in most cases,
this would be generated via proxy.
Check out our ViewModels and Data Binding Guide for more information.
Next, let's look at the Ext.grid.Panel by opening MyApp/classic/src/view/main/List.js.
List.js contains the grid that loads within the first tab of your Main tabpanel. With this minimal
amount of code, we've created a fully functional grid. By default, each column
is sortable and will toggle between ASC and DESC sorting when you click on its header. Each column
header is also re-orderable by default, and each gains a drop-down menu with options to
hide and show columns.
Not only that, but it's incredibly easy to configure each column independently.
Let's dissect a couple of the grid configs a little further:
As you can see, we are setting store to a type of personnel. If you look carefully,
you'll probably notice that there isn't a store definition anywhere in the classic
area. That's because this store lives in the universal area,
app/store/Personnel.js. We have placed the store here so that the Classic grid AND the
Modern grid can share the same store and data.
In a real world situation, the above store would have a proxy with a url property allowing the proxy to pull information from a server. We are keeping the data in-line in this example for the sake of visualization. However, most situations would not call for having in-line data.
You'll also notice that the Listeners object contains a select event that calls 'onItemSelected'.
Again, you won't find a view controller with that logic in the Classic area. You will find
MainController.js in the universal section because both Modern and Classic's grid share the select
event and react to it similarly.
If you haven't already, let's open app/view/main/MainController.js.
You'll see some very basic logic:
onItemSelected: function (sender, record) {
Ext.Msg.confirm('Confirm', 'Are you sure?', 'onConfirm', this);
},
In both our grid and the Modern toolkit's grid (more in a minute), we are handling
the select event. The controller logic handles both components’ select events identically.
We'll talk more about universal controllers further down the page.
We've covered most of the meat and potatoes from the Classic toolkit. Let's move on to the Modern toolkit.
As with Classic, let's begin by reviewing MyApp/modern/src/view/main/Main.js.
This is the main entry point to our Modern application. In much the same fashion, you'll notice
Main is a container that houses our tabpanel, and its four tabs. Additionally, you'll see the first tab
includes our Modern Grid.
Modern toolkit's tabpanels are a great way to allow the user to switch between several views that are all fullscreen. Each Component in the TabPanel gets its own Tab, which shows the Component when tapped. Tabs can be positioned at the top or the bottom of the TabPanel.
You'll see many similarities between this view and the Classic view. For instance:
The Modern Toolkit includes a lightweight grid that is optimized for touch devices. The Modern grid makes it easy to fetch, sort, filter, and edit large amounts of data on touch devices. It’s also simple to configure and customize any column using column renderers.
As with the Classic Toolkit's grid, you can see a shared universal store and a listeners
object that is capturing the select event.
We've touched on all of the code sitting within the universal section of our application. That said, you'll need to make sure you're careful and consistent when utilizing this space. At this time, you should avoid placing application views themselves in the universal section. If you require or make reference to a class that does not exist in one toolkit or the other, you'll encounter errors when building your application.
This area should generally be reserved for things found in the core of both toolkits.
Going forward, we are working towards component parity so that sharing view terminology will be less of a concern in the future.
Lastly, you'll want to be sure that any events you're trying to utilize have the same parameters and are triggered with the same intent across both toolkits.
Now let's focus on the look and feel of the application. The default theme (Triton) is generated with every new application unless told otherwise. That said, it's incredibly easy to swap themes once your application has been created.
Let's try out the Ext JS Crisp theme.
All you need to do is open your app.json file in your application root and update the
theme property from:
"theme": "theme-neptune"
to:
"theme": "theme-crisp"
Once watch has completed, refresh the page and you should see that your application has gotten a face-lift.
On most occasions, you'll need to customize the look of your application beyond the capacity of a default theme. Your application looks pretty good, but blue just isn't working. Let's try and get those active tab colors to be more unique to our application.
Note: The following steps will style the classic views within your application. In the near future, Ext JS 6 will be improved to allow for theming the views of both toolkits within the same application.
You can easily and efficiently style your application by creating and modifying SCSS files.
SCSS (Sassy CSS) is a syntax of SASS, which allows you to add nested rules, variables and mixins to your design code. These new additions are then processed and converted to traditional CSS files for your application's consumption.
To see a list of global SCSS variables, check out this page from our API docs: Global_CSS
Individual components also have specific SCSS variables for you to change. For instance, you can view specific Panel SCSS variables by visiting the Panel API page and scrolling to the “CSS Variables” section: Ext.panel.Panel
If you open up your classic/sass/src/view/main/ folder, you'll see a file called
Main.scss. These folders and files will need to be added manually as needed. For
each class in your application, Sencha Cmd checks for a corresponding SCSS file in
sass/var/ for variables, and sass/src/ for rules.
These files will be picked up by sencha app watch when you add them.
Let's go ahead and look at our Main.scss file.
As you can see, we have some specific SCSS rules set up for the main view. The top panel is set by the following line:
$ui-header-background-color: $base-color,
You have a couple of options here in terms of the scope of your color change. If you
only want this one piece to not be blue, you can explicitly set it to a specific color like so:
$ui-header-background-color: #87BD3E,
Once the change is picked up and processed by watch, you can refresh your page and see that your active tab color is now green (#87BD3E).
However, if you want to replace blue for green across the entire application, you can change
the value of $base-color. In order to do this, create an SCSS file for your global
rules in the following location:
classic/sass/etc/all.scss // all.scss may contain any SASS / CSS rules
Once you've created your file, you can add a new $base-color declaration that will
override the app theme's $base-color value. In this case, let's do the same green.
$base-color: #87BD3E dynamic();
After your application is refreshed, you should now see that many components are that color of green.
Now you see how easy it is to get an application up and running using Ext JS and Sencha Cmd. Make sure to check out the API docs for all of the Components and classes that we explored throughout this walkthrough.
Ext JS | Terms of Use