Sencha Touch 2的訪問歷史和路由支持堪稱獨有特色，也讓它的用戶體驗向Native應用更加靠近了一步。通俗的講，訪問歷史和路由這兩個功能（深鏈接只是路由功能的一個應用）就是在瀏覽器環境中，把單頁面應用程序模擬成多頁面交互的效果，而且還無需刷新頁面。
這篇文章的英文原址是http://docs.sencha.com/touch/2-0/#!/guide/history_support
原文標題是：Routing, Deep Linking and the Back Button（路由、深鏈接以及后退按鈕）。
Sencha Touch 交流QQ群213119459歡迎您的加入。
Routing, Deep Linking and the Back Button
路由、深鏈接和后退按鈕
注：為方便起見，文中所有出現 Sencha Touch的地方均以 ST簡寫替代。
Sencha Touch 2 comes with fully history and deep-linking support. This gives your web applications 2 massive benefits:
ST2帶來了全面的訪問歷史和深鏈接支持，這將賦予我們的應用程序兩個好處：
l The back button works inside your apps, navigating correctly and quickly between screens without refreshing the page
（瀏覽器的）后退按鈕將會在你的應用程序內部發揮作用，從而實現在（應用程序內部的）界面屏幕之間快速正確的導航，而不會刷新整個頁面。
l Deep-linking enables your users to send a link to any part of the app and have it load the right screen
深鏈接功能使得用戶可以把應用程序的任意部分作為鏈接發送出去，當這個鏈接被點擊時頁面會加載到正確的內容（而不是應用程序的初始頁面）
The result is an application that feels much more in tune with what users expect from native apps, especially on Android devices with the built-in back button fully supported.
結果就是你的web應用程序也可以給人帶來如同本地應用一般的舒暢體驗，尤其是對Android設備來說，后退按鈕可以得到最完整的功能支持。
Setting up routes
設置路由
Setting up history support for your apps is pretty straightforward and is centered around the concept of routes. Routes are a simple mapping between urls and controller actions - whenever a certain type of url is detected in the address bar the corresponding Controller action is called automatically. Let's take a look at a simple Controller:
以路由功能為基礎，為應用程序設置訪問歷史功能支持變得很容易。路由其實實現的就是url和控制器動作之間的映射，當地址欄中的一個特定類型url被檢測到的時候，相應的控制其動作就會被自動調用，我們來看一個簡單的控制器例子：
Ext.define('MyApp.controller.Products', {
extend: 'Ext.app.Controller',
config: {
routes: {
'products/:id': 'showProduct'
}
},
showProduct: function(id) {
console.log('showing product ' + id);
}
});
By specifying the routes above, the Main controller will be notified whenever the browser url looks like "#products/123". For example, if your application is deployed onto http://myapp.com, any url that looks like http://myapp.com/#products/123, http://myapp.com/#products/456 or http://myapp.com/#products/abc will automatically cause your showProduct function to be called.
通過上述路由的定義，當瀏覽器url是類似#products/123的時候，Main控制器（譯者注：懷疑作者寫錯了，應該是Products控制器）就會被通知。例如，你的應用程序部署在http://myapp.com這個路徑，那么凡是類似http://myapp.com/#products/123，http://myapp.com/#products/456，http://myapp.com/#products/abc這樣的url都會自動調用你的showProduct方法。
When the showProduct function is called this way, it is passed the 'id' token that was parsed out of the url. This happens because we used ':id' in the route - whenever a route contains a ':' it will attempt to pull that information out of the url and pass it into your function. Note that these parsed tokens are always strings (because urls are always strings themselves), so hitting a route like 'http://myapp.com/#products/456' is the same as calling showProduct('456').
當showProduct方法這樣被調用的時候，其實它被傳遞了id這個參數，這是因為我們在路由中使用了“:id”，當一個路由包含了“:”的時候，他會被視作參數名然后把對應的值從url中獲取出來并傳給你的函數。注意這些解析出來的參數總是以string類型出現的，因為url本身就是個string類型。所以訪問一個類似http://myapp.com/#products/456這樣的路由其實就等于調用了showProduct('456')方法。
You can specify any number of routes and your routes can each have any number of tokens - for example:
你可以定義多個路由，每個路由也可以包含多個參數，比如：
Ext.define('MyApp.controller.Products', {
extend: 'Ext.app.Controller',
config: {
routes: {
'products/:id': 'showProduct',
'products/:id/:format': 'showProductInFormat'
}
},
showProduct: function(id) {
console.log('showing product ' + id);
},
showProductInFormat: function(id, format) {
console.log('showing product ' + id + ' in ' + format + ' format');
}
});
The second route accepts urls like #products/123/pdf, which will route through to the showProductInFormat function and console log 'showing product 123 in pdf format'. Notice that the arguments are passed into the function in the order they appear in the route definition.
第二個路由接受像#products/123/pdf這樣的url，它將被指向showProductInFormat函數并且輸出'showing product 123 in pdf format'結果。注意傳入函數的參數順序與路由中定義的順序保持一致。
Of course, your Controller function probably won't actually just log a message to the console, it can do anything needed by your app - whether it's fetching data, updating the UI or anything else.
當然你的控制器函數不會只是輸出一段調試信息，你可以根據需要做任何事情，獲取數據、更新界面或者其他什么的都行。
Advanced Routes
路由進階
By default, wildcards in routes match any sequence of letters and numbers. This means that a route for "products/:id/edit" would match the url "#products/123/edit" but not "#products/a ,fd.sd/edit" - the second contains a number of letters that don't qualify (space, comma, dot).
默認情況下，路由中的通配符可以匹配任意連續的字母和數字字符串。比如"products/:id/edit"這個路由可以匹配"#products/123/edit"，但是卻不能匹配"#products/a ,fd.sd/edit"，后面這個url包含了一些非法字符（空格，逗號，點號）
Sometimes though we want the route to be able to match urls like this, for example if a url contains a file name we may want to be able to pull that out into a single token. To achieve this we can pass a configuration object into our Route:
但是有時候我們還是需要路由能夠匹配類似的url，比如我們的url包含一個文件名，我們想把它取出來。這時可以傳遞一個配置對象到路由中去：
Ext.define('MyApp.controller.Products', {
extend: 'Ext.app.Controller',
config: {
routes: {
'file/:filename': {
action: 'showFile',
conditions: {
':filename': "[0-9a-zA-Z\.]+"
}
}
}
},
//opens a new window to show the file
showFile: function(filename) {
window.open(filename);
}
});
So instead of an action string we now have a configuration object that contains an 'action' property. In addition, we added a conditions configuration which tells the :filename token to match any sequence of numbers and letters, along with a period ('.'). This means our route will now match urls like http://myapp.com/#file/someFile.jpg, passing 'someFile.jpg' in as the argument to the Controller's showFile function.
也就是說可以使用一個包含了action屬性的配置對象來取代action字符串。除此之外，我們給這這個對象添加一個conditions屬性，這個屬性定義了:filename這個參數可以匹配英文數字、阿拉伯數字外加一個英文點號。這樣我們的路由現在就可以匹配像http://myapp.com/#file/someFile.jpg這樣的url了，它會把someFile.jpg作為參數傳遞給控制器的showFile函數。
Restoring State
還原狀態
One challenge that comes with supporting history and deep linking is that you need to be able to restore the full UI state of the app to make it as if the user navigated to the deep-linked page him or herself. This can sometimes be tricky but is the price we pay for making life better for the user.
伴隨訪問歷史支持和深鏈接而來的挑戰就是你得想辦法還原整個UI界面的狀態，來使得整個界面看起來像是用戶自己一步一步導航過去似的。這的確很棘手，但卻是我們為了提高用戶體驗而不得不付出的代價。
Let's take the simple example of loading a product based on a url like http://myapp.com/#products/123. Let's update our Products Controller from above:
我們來看一個小例子，怎樣加載http://myapp.com/#products/123這個鏈接指向的頁面內容，代碼是從上面Products控制器改動而來：
Ext.define('MyApp.controller.Products', {
extend: 'Ext.app.Controller',
config: {
refs: {
main: '#mainView'
},
routes: {
'products/:id': 'showProduct'
}
},
/**
* Endpoint for 'products/:id' routes. Adds a product details view (xtype = productview)
* into the main view of the app then loads the Product into the view
*
*/
showProduct: function(id) {
var view = this.getMain().add({
xtype: 'productview'
});
MyApp.model.Product.load(id, {
success: function(product) {
view.setRecord(product);
},
failure: function() {
Ext.Msg.alert('Could not load Product ' + id);
}
});
}
});
Here our 'products/:id' url endpoint results in the immediate addition of a view into our app's main view (which could be a TabPanel or other Container), then uses our product model (MyApp.model.Product) to fetch the Product from the server. We added a callback that then populates the product detail view with the freshly loaded Product. We render the UI immediately (as opposed to only rendering it when the Product has been loaded) so that we give the user visual feedback as soon as possible.
'products/:id'這個路由映射的目標應該是立刻把一個detail視圖加入到應用程序的main視圖（可能是一個tabpanel或者其他container）里面去，之后通過product數據模型（MyApp.model.Product）從服務器取回product信息，并在回調里把最新獲取到的數據發布到product的detail視圖上，然后立刻渲染UI界面（與之相對照的是在Product被加載之后才渲染）這樣我們就以最快速度給了用戶他們想要的數據。
Each app will need different logic when it comes to restoring state for a deeply-linked view. For example, the Kitchen Sink needs to restore the state of its NestedList navigation as well as rendering the correct view for the given url. To see how this is accomplished in both Phone and Tablet profiles check out the showView functions in the Kitchen Sink's app/controller/phone/Main.js and app/controller/tablet/Main.js files.
每個應用程序在為深鏈接還原狀態的時候都有不同的邏輯。比如Kitchen Sink需要還原他的級聯列表導航欄并渲染url指定的視圖。想知道在Phone和Tablet兩個Profile中是怎么實現的，請參考Kitchen Sink的 app/controller/phone/Main.js和app/controller/tablet/Main.js文件中showView函數。
Sharing urls across Device Profiles
跨設備配置共享url
In most cases you'll want to share the exact same route structure between your Device Profiles. This way a user using your Phone version can send their current url to a friend using a Tablet and expect that their friend will be taken to the right place in the Tablet app. This generally means it's best to define your route configurations in the superclass of the Phone and Tablet-specific Controllers:
大部分情況下，我們都希望在不同設備配置之間共享同樣的路由架構。這樣的話一個使用手機界面的用戶可以把自己當前的url發送給使用平板電腦界面的朋友，并且還能保證朋友在平板電腦上看到的也是同樣內容。這意味著我們最好在一個父類中定義route配置，然后由手機和平板的控制器分別繼承該父類的配置：
Ext.define('MyApp.controller.Products', {
extend: 'Ext.app.Controller',
config: {
routes: {
'products/:id': 'showProduct'
}
}
});
Now in your Phone-specific subclass you can just implement the showProduct function to give a Phone-specific view for the given product:
現在phone專用的子類當中你只需要繼承這個showProduct函數并顯示一個手機下專用的視圖即可：
Ext.define('MyApp.controller.phone.Products', {
extend: 'MyApp.controller.Products',
showProduct: function(id) {
console.log('showing a phone-specific Product page for ' + id);
}
});
And in your Tablet-specific subclass just do the same thing, this time showing a tablet-specific view:
在平臺專用的子類當中也要做同樣的事情，只不過這次調用的是一個平臺電腦下專用的視圖：
Ext.define('MyApp.controller.tablet.Products', {
extend: 'MyApp.controller.Products',
showProduct: function(id) {
console.log('showing a tablet-specific Product page for ' + id);
}
});
There are some exceptions to this rule, usually to do with linking to navigation states. The Kitchen Sink example has phone and tablet specific views - on both profiles we use a NestedList for navigation but whereas on the Tablet NestedList only takes up the left hand edge of the screen, one the Phone it fills the screen. In order to make the back button work as expected on phones, each time we navigate in the NestedList we push the new url into the history, which means that the Phone-specific controller has one additional route. Check out the app/controller/phone/Main.js file for an example of this.
也有一些例外情況，比如Kitchen Sink例子當中有phone和tablet兩個專用視圖，兩個profile中都有一個級聯列表作為導航欄，但是平板電腦上的導航欄是一直固定在左側不動，而手機上的則是充滿整個屏幕。為了使手機上的后退按鈕可以正常工作，每次我們在手機級聯列表中導航的時候都要設定一個新的url到訪問歷史當中去，這樣手機專用的控制器就會多一個額外的路由，具體可以看一下app/controller/phone/Main.js文件當中的代碼。
浙公網安備 33010602011771號