一堆網址的模式

Question

我有一個以下問題。我們有一個應用程序，它基本上是一組控制與用戶交互的JSP和操作類。這些操作設置了頁面正確顯示所需的一些參數。系統中的網址總是包含事件的名稱，該名稱定義了我們應該接下來的頁面。

現在，幾乎每個頁面都有一個「取消」按鈕，它應該會導致前一頁。從一開始，每個取消按鈕url都被嚴格定義，但最終，隨着系統變得越來越大，事實證明，編寫此按鈕的邏輯非常困難，因此它會完全導致前一頁。

例如，假設我們有三個頁面A，B和C.頁面A有一個通向頁面B的鏈接，B有一個通向C的鏈接。因此C有一個甚至導致B的URL（和它也包含實體在B）上顯示的關鍵。但是，假設頁面A已被修改，現在還有一個關於C的鏈接。現在我們需要檢查從那裏出現的C頁面並適當地設置URL，並且邏輯變得相當混雜。

所以，我向我的團隊提出了以下解決方案。用戶會話應該包含一個名爲CancelStack的特殊對象。每一個導致頁面的動作都應該將它的url放到堆棧中（包含事件和一些所需的附加數據）。在每個頁面上，取消按鈕現在應該有一個通往特殊事件的URL，稱爲cancelStack。

什麼cancelStack行動確實是這樣的：

• 從會話中檢索取消堆棧。
• 彈出最後一個網址，不要使用它。
• 再次彈出網址並重定向到該網址。

爲什麼我們檢索最後一個URL而不使用？假設我們有頁面A和B，A導致B.A的操作將它的URL放入堆棧中，並且這應該是B頁面的取消URL。現在，針對B的操作將它的url放入堆棧中。因此，我彈出它沒有使用，然後彈出第一個網址，重定向到一個動作，並且這個動作再次添加一個網址到堆棧（因此堆棧大小減少1，而不是2）。

這似乎是一個很好的方案，但是看起來相當奇怪的是堆棧的頂層元素被彈出而沒有使用。所以我有個問題。是否有任何設計模式來存儲會話中的URL序列以正確組織取消按鈕？

Answer 1

你做的事對我來說似乎是合理的。說實話，我現在無法想象解決您的問題的設計模式，但我認爲如果除了cancelStack之外，您仍然參考currentURL，以便只有在您沒有結束時纔將currentURL推入堆棧一個取消頁面，你將擺脫額外的pop，讓你煩惱。
否則你只需pop頂部cancelStack。
例如在你的榜樣：

假設我們有一個頁面A和B，A領先於B ...

currentUrl是A.行動爲A未取消如此currentUrl即A推到cancelStack 。那麼它的動作爲B和currentURL爲B，但操作取消，因此B未放置在堆棧中。所以cancelStack的頂部是A（而currentUrl是B）。所以如果你popcancelStack你檢索A（沒有額外的pop需要）