Sencha Touch 2 Official document translation Intro to applications with Sencha Touch 2 (Introduction to ST2 applications)

Original address: http://www.cnblogs.com/dowinning/archive/2012/02/14/2350303.html

Objective:

It is always difficult to read English documents, and the non-native and professional speeches are easily discouraged and impetuous, which leads to inefficient learning.

Translation is a good way to translate the learning needs into the task of translation, forcing oneself not only to see, to understand, but also to carve, and then clear expression, the results of this study in translation is undoubtedly the most solid, and finally your translation can help others.

The English site of this article is Http://docs.sencha.com/touch/2-0/#!/guide/apps_intro

The original title is:Intro to applications with Sencha Touch 2(Sencha touch 2 application Introduction). Interestingly, the description given to it in the official documents directory is all about applications (everything about the app) , read it carefully and you will find that this article is actually the master of Sencha Touch MVC, for understanding Sencha The MVC pattern of touch was significant and had to be read, so I took it as the first article in this series of translations. In view of my limited level, improper translation and even the fallacy of the inevitable, but also hope that everyone's generous enlighten.

This original translation first published in their own blog, the subsequent updates will be published in the first time, please pay attention. In addition, I also built a QQ group (group number 213119459) to facilitate the exchange of Sencha touch enthusiasts, you are welcome to join.

Original address: http://www.cnblogs.com/dowinning/archive/2012/02/14/2350303.html

Intro to applications with Sencha Touch 2

Sencha Touch 2 Introduction to Applications

Note: For convenience, all occurrences of Sencha Touch in the text are substituted with ST shorthand.

Sencha Touch 2 is optimized around building applications this work across multiple platforms. To make the writing of applications as simple as possible, we provide a simple but powerful application architecture that Leverages the MVC (Model View Controller) pattern. This approach keeps your code clean, testable and easy to maintain, and provides if you have a number of benefits when it com Es to writing your apps:

ST2 is designed to be optimized for building (web) applications that work across multiple platforms. To make it as easy as possible for you to write your application, we offer a simple but powerful application architecture that can be seen as an extension of the MVC (model/model, view/view, controller/Controller) pattern. Writing your application in this mode will not only ensure that your code is clean, easy to test, easy to maintain, but also benefit from the following benefits: The full Back button support inside your app, and any Part of your app can is linked to
Access History support : Your app will get full back button functionality, any part of which can be linked to deep linking: The share deep links the open any screens in your app, Just like linking to a Web page
Deep links : As in previous links to a Web page, deep links can open any screen Device in your application Profiles: Easily customize your application ' s UI For phones, tablets and other devices while sharing all of the common code
Device Profiles : Easily customize the application UI (user interface) for phones, tablets, and other devices while sharing common code

Anatomy of an application

Application Structure Resolution

An application are a collection of Models, views, Controllers, Stores and Profiles, plus some additional metadata specifyin G things like application icons and launch screen images.

The ST application is a collection of Model, View, Controller, Store, profile, plus some additional specified metadata, such as icon icons and images displayed on the splash screen.

Models: Represent a type of object in your app-for example an E-commerce app might has models for Users, products and ORD ERs
Data Model:Represents a data model in an application, such as an e-commerce application that may have different data models for users, products, orders, etc. views: is responsible for displaying data to your users and leverage the built in the Sencha Touch
View:Responsible for presenting the data to the user and expanding the built-in components of Sencha Touch. (Translator Note: You can understand as a part of the user interface)Controllers: Handle interaction with your application, listening for user taps and swipes and taking action accordingly
Controller:Handles the interaction of the application, listening to the user's touch, bash (translator Note: The true meaning is a long press.) ) and respond accordingly.Stores: is responsible for loading data to your app and power components like Lists and DataViews
Data Memory:Responsible for loading data into your app and showing it in list or Data View (DataView)Profiles: enable you to easily customize your app's UI for tablets and phones while sharing as much code as possible
Device configuration:Allows you to easily customize the application user interface for different devices, such as tablets and phones, and share the code as much as possible

The application is usually the first thing your define in a Sencha Touch application, and looks something like this:

The Application object is usually the first thing you need to define when you develop an ST application, like this:

Ext.application ({

Name: ' MyApp ',

Models: [' User ', ' Product ', ' nested. Order '],

Views: [' orderlist ', ' OrderDetail ', ' Main '],

controllers: [' Orders '],

Launch:function () {

Ext.create (' MyApp.view.Main ');

}

});

The name is used to create a single global namespace for your entire application, including all of its models, views, cont Rollers and other classes. For example, an app called MYAPP should has its constituent classes follow the pattern MyApp.model.User, Myapp.controller . Users,myapp.view.main etc. This keeps your entire app under a single global variable so minimizes the chance of other code on the page conflicting wi Th it.

As the code shows, there is a name attribute in the application constructor parameter, which creates a unique namespace for your application that contains all of the model, view, controller, and other class (classes) of the application, such as a MyApp Applications should be organized in the following form: MyApp.model.User, MyApp.controller.Users, MyApp.view.Main, etc., which ensures that your entire application is under a unique global variable, This minimizes the likelihood of code conflicts.

The application uses the defined models, views and controllers configurations to automatically load those classes into R app. These follow a simple file structure Convention-models is expected to BES in the App/model directory, controllers in the App/controller directory and views inside the App/view directory-for example App/model/user.js, App/controllers/orders. JS and App/view/main.js.

The application will follow the models that you have defined in the application constructor, and the views and controllers attribute members are loaded from their corresponding class (class) to the current application, and the file structure of the ST2 schema contract is as follows: Model is placed in App/mo Del Directory, the controller is placed in the App/controller directory, the view is placed in the App/view directory, such as App/model/user.js, App/controller/orders.js, App/view/ma In.js (Translator Note: The original text of the path of the Orders.js file is wrong, model, view, controller of the three directory names are not s)

Note that one of the models we specified is different to the others-we specified the full class name ("MyApp.model.nest Ed. Order "). We ' re able to specify the full class name for any of those configurations if we don ' t follow the normal naming conventions . See the Dependencies sections of the Ext.app.Application docs for full details on what to specify custom Dependencies.

Note that the definition of one member in the models attribute is different from the others, ("MyApp.model.nested.Order"), in addition to following the general naming format described above, we can also define these configurations using the full class name, in other words application Models, views, controllers in the constructor can all be defined in the form of a full class name, for more details on how to define dependencies, see the article Dependencies section of the Ext.app.Application Docs (Dependencies chapters in the Ext.app.Application documentation)

Controllers

Controller

Controllers is the glue the binds an application together. They listen for events fired by the UI and then take some action on it. This helps to keep we code clean and readable, and separates the view logic from the control logic.

The controller, like glue, glues out a complete application that listens to events triggered by the UI interface, then makes the corresponding actions, and makes our code more concise and readable, isolating the interface logic from the control logic.

For example, let's say you require the users to log on to your app via a login form. The "View in" is the "the" and "all" of its fields and other controls. A controller should listen to tap event on the form's submit button and then perform the authentication itself. Any time we deal with manipulating data or state, the controller should is the class that activates the change and not a vie W.

If you need a user to log into your application via a login form, the view is the form that contains all the fields and other elements, and its controller (director) is going to listen for the touch event of the form Submit button and authenticate it. Each time we are dealing with data or state, the controller is the class that should work, not the view.

Controllers expose a small but powerful set of features, and follow a few simple conventions. Each Controller in your application are a subclass of Ext.app.Controller (though you can subclass existing Controllers, so Long as it inherits from Ext.app.Controller to some point). Controllers exist in the myapp.controller.* namespace-for example if your app had a Sessions controller it would is call Ed MyApp.controller.Sessions and exist in the file app/controller/sessions.js.

The controller, through some simple conventions, shows a small but powerful set of features. Each controller of the application is a subclass of Ext.app.Controller, and of course you can inherit from the existing controller, as long as it is also inherited from Ext.app.Controller, Controller (controllers) exist in the Myapp.controller.* namespace, for example your application has a controller called Sessions, then its full namespace will be MyApp.controller.Sessions and is defined in the App/controller/sessions.js file.

Although each Controller was a subclass of Ext.app.Controller, each one was instantiated just once by the application that L Oaded it. There is a ever one instance of each controller at any one time and the set of controllers instances is managed internal Ly by the application. Using application ' s controllers config (as we do above) loads all of the controllers and instantiates them automatically.

Each controller (director) is a subclass of Ext.app.Controller, and the application that loads it only instantiates it once, and the application itself controls that each controller (director) has only one instance at a time. We use the controllers parameter of the Application object to load the controller (Director) and automatically instantiate them.

A Simple Example

A simple example

Here's how we might quickly define the Sessions controller described above. We ' re using 2 Controller configurations here-refs and control. Refs is an easy-to-find components on your page-in this case the Controller would look for all components that match The Formpanel Xtype and assign the first one it finds to the LoginForm property. We ll use this property in the Dologin function later.

Here is how to quickly define the Sessions controller described above, and we will use the two configuration parameters of the controller, refs and control, refs is a simple way to find the page component, in this case the controller will search all Formpanel type of control, and then assigns the first value found to the LoginForm property, which is used in the Dologin method below.

The second thing it does is set up a control configuration. Just like refs, this uses a componentquery selector to find all Formpanel xtypes that contain a button inside them (for ex Ample, this would find the Submit button in our hypothetical login form). Whenever any button of the this type fires it tap event, our Controller's Dologin function would be is called:

And then what we're going to do is to configure the control parameter, like refs, to use the Componentquery selector to find all the button controls under Formpanel that contain the button control, in this case, we'll get the commit button in our login form, any one of the characters A button with this condition triggers the tap event, and the controller will call the Dologin function.

Ext.define (' MyApp.controller.Sessions ', {

Extend: ' Ext.app.Controller ',

Config: {

Refs: {

LoginForm: ' Formpanel '

},

Control: {

' Formpanel button ': {

Tap: ' Dologin '

}

}

},

Dologin:function () {