Original article: http://www.sencha.com/blog/architecting-your-app-in-ext-js-4/
The scalability, maintainability, and flexibility of applications depend on the quality of the application architecture. Unfortunately, this is often regarded as an afterattack. Concept Design and prototype have become large-scale applications. The basic of many applications is examples.CodeThis is attractive because it allows you to make a quick progress in the initial stage of the project.
However, the time saved is not as long as the maintenance, expansion, or even reconstruction of applications in the later stage of the project. A better way is to write a reliable architecture. before implementation, write the following conventions and define the view, model, storage, and Controller of the application. In this articleArticleWe will see a popular application and discuss how to build user interfaces to create a reliable architecture.
Code structure
ApplicationProgramThe architecture system will provide structure and consistency for the actual class and framework aunt. Building a good architecture has the following benefits:
■ Each application works in the same way, so you only need to learn it once.
■ It is easy to share code between applications because they work in the same way.
■ You can use the extjs generation tool to create an optimized release version for your application.
When creating your application in extjs 4, consider the conventions we have defined, especially the unified directory structure. This structure requires that all class files be stored in the app directory. Under this directory, you can create four sub-directories, including models, views, controllers, and stores, based on the namespace.
Although extjs 4 provides the best practice for building your application, you can also modify the naming conventions of recommended files and classes as needed, for example, you can add a prefix to your controller, for example, "users" to "userscontroller ". In this case, remember to prefix all controller files and classes. The most important thing is to define and comply with these conventions before writing an application. In this way, you can call these classes wherever needed. We strongly recommend that you follow the naming conventions for the Four folders controller, model, store, and view. This ensures that you can use the SDK Tools Beta
Optimize the application.
Finding a balance point
View
Splitting the application UI into a view is a good start. The common practice is that you provide wireframes while the designer creates the UI entity model. Try using the following model to let our designers use extjs to reconstruct (very attractive) Pandora applications.
We need to strike a balance between view granularity and versatility. Let's see what happens when too many views are divided.
Dividing the UI into too many small views makes it difficult for the view to be managed, referenced, and controlled in the controller. In addition, because each view has its own file, creating too many views makes it difficult to find the View File when defining the UI block or view logic.
On the other hand, we do not want the view to become too generic, because it will lose flexibility during modification.
In this case, each view is too simplified. When several components of a view need to customize the view logic, the view class will have too much burden and the resulting View class becomes difficult to maintain. In addition, when designers consider changing the UI, We Have To refactor the view definition and view logic, which is quite annoying.
When we can easily rearrange views on the page and do not need to refactor them every time, it means that we have achieved a balance. For example, we can use an ad as an independent view, so that I can move it in a container or even delete it.
In this version, we divide the UI Based on The View task. Once you have an overall idea of using the view combination UI, you can adjust the granularity when implementing them. Sometimes, you may think that two views should be one, or the view is too common and needs to be divided into multiple views, which is a good foundation for the beginning. I believe we have done this.
Model
Now we have the basic structure of the view. It is time to consider the model. By examining the types of Dynamic Data in the UI, we can obtain different models required by the application.
We have decided to use only two models: Song and station. We can define two more models: artist and album. However, similar to a view, we do not want to define a model that is too common. In the current situation, we do not need to separate the artist and album information, because the current application does not allow users to select song based on the specified artist. On the contrary, data is organized by station, and song is the focus, while artist and album are the attributes of song. This means that we cannot combine song, artist, and album into a model. This greatly simplifies the data boundaries of applications. This can also simplify the server-side API, so we do not need to load artists and albums. Therefore, for this example, only two models are required: Song and station.
Stores
Now we need to consider how to use the model in the application, that is, how to design the store.
It is easier to figure out the store that needs to be used. A good policy is to first determine all components on the page that need to bind data. In the current situation, we need to List Users' favorite stations, a scroler that shows recently played songs, and a search area to display the search results. Each view must be bound with a store.
Controller
There are several ways for you to publish application responses through the Application controller. Let's start to consider the controllers required in the current example.
There are two basic controllers: songcontroller and stationcontroller. Extjs 4 allows you to use a single control to control several views at the same time. Stationcontroller should deal with the creation of new stations, and apply it to the stationlist view after the user's favorite station is loaded. Songcontroller manages the songinfo view and updates recentsong store based on the user's liking, disliking, pause, and skip operations. The controller can interact with each other through application event triggering and listening. When we can create the remaining controllers, one for managing playback and the other for searching stations, I think we have found a good way to divide the response.
Think twice
We will share our ideas and focus on helping you plan the application architecture before writing code. We hope that the detailed discussion of the application will help you build a more flexible and easy-to-maintain architecture.
Author:
Tommy maintz
Tommy maintz leads the development of sencha touch. with extensive knowledge of Object Oriented JavaScript and mobile browser idiosyncracies, he pushes the boundaries of what is possible within Mobile browsers. tommy brings a unique view point and an ambitious philosophy to creating engaging user interfaces. his attention to detail drives his desire to make the perfect framework for developers to enjoy.