提交按鈕 + GWT 歷史

Question

提交表單時的良好設計解決方案，“返回”然后“前進”瀏覽器按鈕的行為應該是什么。 類似的問題是當用戶注銷應用程序然后單擊“轉發”瀏覽器按鈕時會發生什么？

我很高興聽到上述情況的一些場景。

謝謝。

編輯-應該很好分享和我的觀點:-)

我個人的意見是注銷后用戶應該無法通過登錄頁面在沒有 go 的情況下進入應用程序。 對於提交場景 - 提交並返回瀏覽器按鈕后，用戶應該能夠返回到表單但不包含任何數據。

Answer 1

使用 state 機器來保留用戶（會話）並請求 state 是很常見的。 如果您有這樣的 state 機器，那么您知道用戶正在嘗試錯誤的轉換。 根據用戶 state 和錯誤的轉換，您可以將用戶轉發到頁面。 例如，如果用戶嘗試 go 到需要登錄但她/他已經注銷的頁面，您可以將她/他發送到登錄頁面，但您可以提供用戶名並且只詢問密碼。

要添加此功能，您可以通過在代碼中硬編碼 state 機器來編寫自己的代碼，或者您可以使用可用的庫之一。 例如， Spring Web Flow為 Spring 框架提供了此功能。

Answer 2

一種常見的模式是Post/Redirect/Get 。 在這種模式下，帖子的結果是一個可添加書簽的（並且向后/向前導航）頁面。 后退按鈕的通常含義之一是“我不是故意要 go 在這里，帶我回到我原來的位置”，就像在大多數 Windows 對話框中按 ESC 一樣，前進按鈕的意思是“我不是故意要回擊按鈕，畢竟我想要那個頁面。” 這種模式並不適用於所有人。 當每個頁面（包括對表單提交的響應）代表一些您想要添加書簽的概念實體時，它最有意義。

至於注銷場景，大多數應用程序都會檢查您是否已登錄，無論 URL 中指定了哪個頁面，如果您未登錄，則重定向到登錄表單。（您不必在每個頁面；檢查通常是 Valve 或其他東西。）一個不錯的功能是記住用戶嘗試 go 的位置，並在成功登錄后將其帶到那里。

您的問題更多是關於設計而不是技術，因此 GWT 並沒有真正改變情況，只是要注意 GWT 歷史機制旨在模仿 static 頁面的行為，鏈接也通過鏈接連接的直接獲取模式.