GAE：路線與標準

在最後幾天，我看到了很多代碼，例如GAE Boilerplate，幾乎所有代碼都使用路線來管理頁面調用。我想知道爲什麼？官方的例子總是使用「正常」的方法：GAE：路線與標準

app = webapp2.WSGIApplication([('/', MainPage), 
           ('/lang', ChangeLanguage)], debug=True)

，但現在我發現這個替代方案：

from webapp2_extras.routes import RedirectRoute 

RedirectRoute('/lang/<lang>', ChangeLanguage, name='lang', strict_slash=True), 
RedirectRoute('/', MainPage, name='home', strict_slash=True)

在第一種情況下，我使用的參數傳遞就要求我的增值經銷商（像/lang?hl=en_US），並在第二我必須通過它作爲一個路徑（如/lang/en_US）。

但爲什麼使用一種方法或其他？有什麼優勢嗎？

另外，我注意到在第一種方法中，我的表單可以在get和put方法中調用，例如/register，但是對於路由，可以調用相同的作品，但是當完成一篇文章時，它只適用於表單動作爲/register/（最後一個斜槓）。

來源

2013-07-18 Eagle

通過原始webapp引入的主要功能之一webapp2恰恰是Route類提供的功能的擴展。

文檔給出了它試圖實現一個很好的解釋：

webapp2的介紹，它擴展了Web應用程序的模型，以提供額外功能的路由機制：

URI建設：可以根據需要構建註冊路線，避免應用程序代碼和模板中的硬編碼URI。如果在開發過程中以兼容的方式更改路由定義，則所有使用該路由的地方都將繼續指向正確的URI。這不易出錯並且易於維護。

關鍵字參數：處理程序可以從匹配的URI接收關鍵字參數。這比使用位置參數更容易使用並且更加可靠。

嵌套路由：可以擴展路由以匹配多於請求路徑。我們將在下面看到一個可以匹配域和子域的路由類。

Source

底線，他們是路由的一個更強大的版本，爲程序員提供了更多的功能。

根據您的具體參數問題，您不必通過lang任何具體的方式。在第一種情況下，lang將作爲request.GET的一部分在第二種情況下作爲與請求方法（GET,POST）相匹配的請求處理程序方法的位置參數提供。

區別主要是在/lang?hl=en_US的情況下，參數在技術上是可選的。即使參數不存在，您的請求仍會與處理程序匹配，因此您必須驗證request.GET包含數據。

在第二種情況下，/lang/en_US，路由只匹配，因此處理程序僅在需要匹配的地方代替<lang>時纔會調用。

根據斜線問題，您在路線中使用strict_slash。 more here

來源

2013-07-18 09:26:45

謝謝@Tomasz。我已閱讀鏈接。只有2個註釋：在某些情況下，似乎可以很好地使用（並檢查）參數是否已經過去。例如，在'lang？hl = en_US'中，如果我沒有找到它，我會拋出「Bad param」的消息。隨着路線啓動404錯誤。其次，根據strict_slash文檔，調用'/ register'將重定向到'/ register /'。那麼，爲什麼POST到'/ register'失敗？但最後，調用'/ register'還是'/ register /'之間的區別，即爲什麼人們使用strict_slash？ – Eagle

@Eagle正確，無論是「lang？hl = en_US」還是「/ lang/en_US」都沒有錯 - 這取決於你，這對你的特定情況更有意義。 –

@Eagle至於'POST'失敗，（當你不清楚什麼是和不能工作時），strict_slash'的效果是當請求的URL發出一個代碼爲「301」的響應（重定向）當預期有一個斜線時會丟失斜線，反之亦然。爲'POST'發出重定向不是我期望在任何地方看到的模式，因爲您應該已經使用最初的'GET'將瀏覽器重定向到正確的URL。這就是爲什麼我相信'webapp2.RedirectHandler'（webapp2的重定向實現的一部分）甚至沒有實現'POST'處理程序。 –

GAE：路線與標準

回答

相關問題