如何在Xpages事件中實現“continue = false”

Question

這是一個相當普遍的問題，但我會盡量精確：

很多時候我會被客戶要求正確實現LotusScript

continue = false

在Notes的Query *事件中。 一個非常常見的情況是表單的QueryOpen事件，其中我們實際上可以基於某些條件（例如，基於來自用戶對話的響應）來停止打開所討論的文檔的過程。

對於像querySaveDocument這樣的一些Xpages事件，有非常明顯的解決方案，而對於其他事件我只能建議重新思考整個邏輯，比如在更早的階段阻止代碼執行。 但當然大多數人都更喜歡像“使用......重寫這些代碼”這樣的通用方法。 並且 - 說實話 - 我想知道自己;）

我或多或少熟悉Xpages / JSF生命周期，但不得不承認我沒有正確的想法如何在任何給定階段停止執行。 一如既往，任何提示都是受歡迎的。

編輯 （澄清我的問題，但也回應蒂姆的答案）：

它不僅僅是QuerySave，而且還有QueryModeChange和QueryRecalc以某種方式需要與一個在線應用程序的邏輯一起轉換，但在Xpages邏輯中沒有它們的等價物。 這兩個概念（基於表單和基於xpages）在這一點上有太大的不同嗎？

例如，考慮一個工作流應用程序，我們需要在允許在編輯模式下為潛在作者打開現有文檔之前檢查某些條件。 在我的Notes客戶端應用程序中，我將一些代碼添加到2個事件，即QueryOpen ，我在其中檢查“ mode ”arg和第二個QueryModeChange ，在那里我檢查當前的doc模式 。 在這兩種情況下，如果需要，我可以通過添加我的continue = false來阻止編輯doc。 根據事件，文檔將不會更改其模式，或者根本不會打開。

使用Xpage我可以使用按鈕來更改文檔的編輯模式，我可以“隱藏”這些按鈕，或者只是添加一些檢查代碼或其他。 但17年的Domino咨詢至少給我上了一課：總會有用戶找到隱藏的方法來實現他們的目標。 在我們的案例中，他們可能會發現對頁面URL的簡單修改最終將允許他們編輯文檔。 為了防止這種情況，我可以使用“ beforeRenderResponse ”事件，我假設。 但是之后，在其他情況下也會調用beforeRenderResponse ，因此我們必須首先調查當前的情況。 或者我可以確保用戶沒有作者權限，除非情況允許。

同樣，這不是一個大問題，但是當從傳統Notes應用程序進行轉換時，這意味着重新思考其整個邏輯。 這使得這項工作更加明顯，而且更加昂貴。

真正？ 或者我錯過了這個概念的一些關鍵部分？

Answer 1

將您的事件構建為操作組，並在適用時返回false 。 這將導致跳過組中的所有剩余操作。

例如，您可以將“保存”按鈕拆分為兩個單獨的操作：

1。

// by default, execute additional actions:
var result = true;
/* execute some logic here */
if (somethingFailed) {
    result = false;
}
return result;

使用基於您所擁有的任何邏輯的評估替換somethingFailed來代替塊注釋，以確定是否適合現在保存文檔。

2。

return currentDocument.save();

如果第一個動作返回false ，上面的模式不僅導致調用save()被跳過，而且因為save()反過來返回一個布爾值，理論上你也可以添加第三個動作作為一種postSave事件：如果保存成功，第三個動作將自動運行; 如果保存失敗，將自動跳過第三個操作。

應將所有queryModeChange邏輯移動到包含所有其他可編輯內容的面板（或XPage或自定義控件的view根）的readonly屬性...您基本上只是翻轉布爾值：傳統上， queryModeChange將處理false （對於Continue ）表示不應編輯文檔（盡管這也會強制您檢查用戶是否嘗試從讀取更改為編輯，因為如果您放棄此檢查，則可能還會阻止用戶更改當模式已經處於編輯狀態時，模式返回讀取，而如果內容不可編輯，則readonly當然應該返回true 。

由於queryModeChange方法幾乎總是一個額外的“無花果葉”安全層，在XPage中通過實際的安全機制來處理這個問題要好得多; readonly屬性明確用於強制執行安全性。 此外，除了使用readonly ，您還可以使用acl complex屬性，該屬性也可用於面板，XPage和自定義控件，以便為不同的用戶子集提供不同的權限。 例如，具有特定角色的任何人都將自動進行編輯，而默認條目的級別可以基於指示當前“狀態”和/或“受讓人”的項目值來計算。 使用這些機制中的任何一個（或兩者），用戶對URL做什么並不重要......如果容器是只讀的，則相關組件不可編輯。 他們甚至可以通過在Chrome開發者工具中運行JavaScript來嘗試入侵，嘗試模擬在他們可以編輯內容時發送的POST請求......他們發送的數據仍然不會被推回到模型中，因為目標組件憑借其容器的屬性是只讀的。

嘗試將所有Notes客戶端模式直接應用於XPage上下文幾乎總是令人沮喪 - 而且最終是徒勞的。 雖然我不會在這里透露細節，但我（以及我認識的一些最聰明的人）以很高的成本學到了這一課。 雖然用戶可能會說（甚至相信）他們想要他們已經擁有的東西......如果他們這樣做了，他們會保留他們已有的東西，而不是付錢給你把它變成別的東西。 因此，從Notes客戶端應用程序到XPage“等效”的任何遷移都是您重新審視代碼執行操作的原因 ，並確定是否有意義保留在XPage中，而不僅僅基於差異Notes客戶機的XPage范式之間，而且對什么之間，當Notes客戶端應用程序開發用戶的業務流程是， 現在他們的過程是什么任何差別。 省略此評估可確保生成的應用程序將運行不需要的代碼，並且無法充分利用目標平台。

queryRecalc就是一個很好的例子：通常，當用戶的桌面和網絡資源負責執行復雜和/或網絡密集的重新計算時，會阻止重新計算以優化性能。 在XPages中，這一切都發生在服務器上，因此來自瀏覽器的網絡請求返回一個頁面，其中所有內容都已更改，對於最終用戶來說，通常不會比沒有任何更改的頁面更昂貴（除非在數量上存在極大差異）實際發送的標記）。 除非組成組件綁定到服務器重新計算的昂貴數據，否則重新計算的邏輯阻止對用戶提供很少或沒有性能優勢。 此外，如果您試圖阻止事件中的重新計算，則為時已晚：XPages使用包含6個階段的“生命周期”，因此，當您的事件代碼運行時，您嘗試阻止的任何重新計算都有已經發生了。 因此，如果阻止重新計算的原因是為了優化性能，請實施范圍緩存策略，以確保只在有意義的情況下提取新數據，並且最終用戶體驗將具有足夠的性能，而不會試圖阻止整個重新計算的頁面。 如果，另一方面， queryRecalc被用作另一個遮羞布（事情已經改變，但我們不希望顯示用戶尚未更新），即邏輯絕對應該重新審查，以確定它是否仍然適用，仍然（如果有的話）一個好主意，平台的哪些部分現在最適合滿足業務流程目標。

總之，使用XPages獨有的安全機制來鎖定部分或全部頁面，並使用我們在Notes客戶端中沒有的內存范圍來確保應用程序運行良好。 將用於包含此邏輯的事件移植到繼續包含此邏輯的XPage事件可能無法產生所需的結果並浪費遷移到XPage的一些好處。