2011-12-02 46 views
42

所有關於骨幹的例子我見過在整個應用中使用一個路由器,但是對於應用的每個單獨部分都有一個路由器(header,footer,stage) ,側邊欄)?有沒有人用多個路由器構建應用程序?您有什麼經驗?BackboneJs中的多個路由器vs單個路由器

讓我們考慮一個帶有嵌套視圖的複雜應用程序:當視圖具有處理子視圖顯示的自己的路由器時,這不是更好嗎,而不是讓一個大型路由器通知主視圖更改它子視圖?

這個問題的背景:我看到很多骨幹路由器和GWT中ActivityMapper的相似之處。 ActivityMapper只負責爲DOM中的給定路線和給定容器獲取正確的演示者。

+5

路由器對象的要點是將一個視圖集合與給定的URL關聯起來,特別是散列之後的部分。這意味着作爲一個外部可導航(和可收藏)的目標。爲什麼有多個路由器是有意義的?你能更清楚地解釋你想達到的目標嗎? –

+1

我希望有具體的問題。 –

+0

偉大的問題安德烈亞斯,這絕對是更多的人隨着他們的應用程序成長而要嘗試做的事情。 –

回答

22

我寫了一個應用程序(仍在寫)與其中的多個路由器。然而,它不像你想象的那樣,它基於更多模塊而不是每個視圖的路由器或類似的東西。

例如, 說我在我的應用程序中有兩個大模塊,1個處理所有書籍,1個處理用戶。 書有多個視圖(如做用戶),列表視圖,詳細視圖,編輯視圖,等等等等...... 所以每個模塊都有自己的路由器, 它代表了自己的一套網址:

// user module... 
var userRouter = Backbone.Router.extend({ 
    routes: { 
     "users": "loadUsers", 
     "users/add": "addUser", 
     "user/:id": "loadUser", 
     "user/:id/edit": "editUser" 
    } 

// ... rest dropped to save the trees (you never know if someone prints this out) 
}); 


// book module 
var bookRouter = Backbone.Router.extend({ 
    routes: { 
     "books": "loadBooks", 
     "books/add": "addBook", 
     "book/:name": "loadBook", 
     "book/:name/edit": "editBook" 
    } 

// ... rest dropped to save the trees (you never know if someone prints this out) 
}); 

所以,它不像我的兩臺路由器在爭奪相同的路由,他們每個人都處理他們自己的一組路由。

編輯 現在,我通過精靈斯騰有更多的信息,我知道這是不是默認可能具有相同的路線上多個路由器匹配。沒有像重寫骨幹歷史或在路由和正則表達式中使用命名空間來匹配這些路由的解決方法。 更多的信息在這裏:multiple matching routes 感謝Elf Sternberg的鏈接。

+0

您可以閱讀Backbone的源代碼以找出答案。但是這裏有一個提示:http://stackoverflow.com/questions/5223251/multiple-matching-routes/ –

+0

沒問題,所以如果沒有一個特定的解決方法,默認骨幹框架就不可能有多個匹配路由。很高興知道,謝謝你的鏈接 – Sander

23

我剛剛在Backbone中寫了一篇關於模塊特定子路由的博客文章,它允許定義一個「子路由」,該路由在之後關注該路由的前綴

檢查出更多的解釋了博客條目:http://www.geekdave.com/?p=13

這意味着你不必一遍遍重複地定義相同的前綴,你也可以延遲加載的子路徑的模塊進行訪問。反饋非常歡迎!

+0

SubRoute擴展是太棒了! – aleha

+1

如果沒有外部鏈接,您的答案不能提供足夠的信息,即使您的博客文章質量很高,也不會提供很好的答案。你應該真的包括一個片段和一些更多的解釋,以回答服務的時間。非常感謝您花時間提供幫助。 –

2

當使用多個路由器時,有一個有限但重要的情況。如果您需要僅基於運行時收集的數據公開應用程序路線的子集(可能是登錄憑據 - 例如,管理員與員工可以看到在不同視圖集之間導航),則只能實例化適當的路由器& View類。這很重要,因爲可以將路由加入書籤並從用戶發送到用戶。當然,您仍然需要在服務器上進行檢查,以確保未經授權的用戶在通過由授權用戶發送的書籤導航到他們到達的視圖後不會發出請求。但最好設計應用程序,以便未經授權的視圖不會生成。