2011-02-24 27 views
0
如何區別不同的路由

所以,我有兩個網址,我需要不同的途徑爲:基於兩個URL

/find-your-new-home/155-detroit/1234-some-value 

/find-your-new-home/155-detroit/5555g-some-other-flipping-value 

我有地方處理#1路線:

routes.MapRoute(
       "FindYourNewHomeCommunity", 
       "find-your-new-home/{market}/{community}.html", 
       new { controller = "Community", action = "Detail" } 
       ); 

我有一個分割「155」,從「底特律」的「詳細信息」方法的動作過濾器,也分裂「1234」,從「一些翻轉的價值」的d只是將ID傳遞給action方法(id的都是重要的,文本值是無關緊要的)。

現在,第二條路線幾乎完全相同,除了「5555」值之後有一個「g」。這個「g」表示它應該在社區控制器上調用另一個操作方法(「CommunityGroup」)。

我的問題是:我如何配置兩條路線分別處理這些?我想:

routes.MapRoute(
        "FindYourNewHomeCommunityGroup", 
        "find-your-new-home/{market}/{communityId}g-{community}.html", 
        new { controller = "Community", action = "CommunityGroup" } 
        ); 

這並不工作,但是,有兩個原因:

1)這兩個網址最後兩條路線相匹配菲爾哈克的RouteDebugger作爲證明。

2)由於貪婪匹配(這就是爲什麼我在示例URL中使用文本「翻轉值」),communityId最終包含「5555-some-other-flippin」,因爲它與最後一次匹配URL中的「g-」,恰好在「翻轉值」文本中。

所以我的問題是,我如何獲得不同的操作方法來觸發這些URL?

編輯:只是爲了澄清,這些URL是由我正在工作的一些其他約束和預先定義,無法更改。他們必須遵循這種格式。

+1

你可以實現你自己的路由處理程序,避免貪婪的匹配。我沒有代碼示例,因爲我只是離開辦公室,但如果沒有人回覆,我會盡量在今晚掏出一些東西。 – Basic 2011-02-24 21:14:24

回答

0

如果你可以生成社區的列表,那麼你可以寫一個自定義的正則表達式約束它將在運行時查找社區併爲您找到它們。然後,它會構建約束條件,只捕捉符合社區要求的路線。一個潛在的問題是它只能在Application_Start上運行。動態改變它會很好。你可以可能通過在運行時更新RouteTable.Routes來做到這一點,但是這是很冒險的。

無論如何,我結束了回答another Stack Overflow question覆蓋相同的地面,here's the answer我寫在那裏。

1

你可以嘗試creating a route constraint,這樣的路線的「communityId」部分將只匹配數字字符,例如:

routes.MapRoute(
    "FindYourNewHomeCommunityGroup", 
    "find-your-new-home/{market}/{communityId}g-{community}.html", 
    new { controller = "Community", action = "CommunityGroup" }, 
    new { communityId = @"\d+" } 
); 
+0

其實我有同樣的想法,並嘗試用你提出的完全相同的語法,但由於貪婪的匹配,它並不總是數字。在我的第二個URL中,communityId將包含「5555g-some-other-flippin」,這顯然不是數字。:) – Scott 2011-02-24 21:45:03

+0

我不明白 - 約束應該強制路線與communityId是數字相匹配,它不會匹配其他方式? – 2011-02-24 21:47:47

+0

只要看看路由,你會認爲communityId只包含「5555」,因此應該與約束匹配。然而,路由匹配是貪婪的,因爲URL中有另一個「g-」(「some-other-flipping-value」 - 翻轉中的最後一個「g」),communityId實際上包含「555g-some-other-flippin」 – Scott 2011-02-24 21:57:23