JSTL和Javascript

Question

在jstl標記內包含標記是否被視為錯誤形式？ 因此，例如，我知道下面的方法會起作用，但是在jsp的jstl標記中包含script標記是否被認為是不好的形式？

<c:choose>
  <c:when test="${!empty bean.value}">
    <p>Its not empty</p>
  </c:when>
  <c:otherwise>
    **<script>
        callJSSomeFunction();
    </script>**
  </c:otherwise>
</c:choose>

Answer 1

我不知道糟糕的形式 （有點苛刻），但是您可能會認為對於在未啟用JS的情況下查看您的頁面的人來說，您的<c:otherwise>不會有效地輸出任何內容，這不是很優雅。

同樣，如果頁面以增量方式呈現，則您的函數調用可能會按照其輸出的狀態執行，並且在DOM被瀏覽器完全加載之前會執行，因此行為無法預測（或根本無法工作-我已經發生了這種情況）。

我會考慮將所有函數調用放在首位，並使用許多可用的技巧之一來檢測DOM何時加載（例如jQuery的$ {document）.ready（） ），以實現更簡潔的分離，並使您的生活變得更加整潔。容易得多。

Answer 2

我不這么認為-這是您有條件地在JSTL中執行操作的方式，我不認為您應該只具有一個腳本標簽。

Answer 3

我現在在打孔器中正在處理一些大型JSTL巨頭，所以我想我應該從UI開發人員的角度出發。

類似SGM的語法包裝了類似SGM的語法的另一個域，這是可怕的形式，但這通常不是您的錯。 您可以通過將它們分開來幫助使其變得更好。 這並非總是可能的，但是您可以設置vars的數量越多，僅在必要時將其放入HTML中就越好。

另一個問題是，您正嘗試直接使用服務器端代碼設置客戶端腳本，考慮到我五年處理UI代碼的經驗，我想說是的，對於您的UI人員來說，它是一個巨大的PITA突然遇到觸發器，他們真的不知道該如何追溯到原點，也沒有任何控制權。 地獄，觸發一切，即使Java開發人員也不一定要確定如果事情夠丑就該如何追根溯源。

想象一下穿着我們的鞋子。 采用服務驅動的體系結構，但讓我們將Java字符串添加到參數混合中，使我們實際上可以從客戶端建立對象方法調用。 這是一個好主意嗎？ 不，這是一個可怕的想法。 並不是因為您不希望JavaScript開發人員編寫Java（您不這樣做-確實使我們感到不愉快），而是因為在分離的這兩點上，事情應該盡可能簡單。 我向您發送數據，您可以根據需要進行處理。

因此，只需將數據交給我們即可。 理想情況下為JSON形式，但我們會忍受任何阻止服務器確定JS執行的事情。 您想要的最后一件事是在您的OOP-murdered-bean-filled牧場中UI蹄踩踏事件，因此不要強迫我們來尋找在HTTP壁兩邊各點之間緊密結合的廢話，這是沒有原因的對我來說很有意義。 我們將消息包裹在岩石周圍，然后將它們卡在牆上。 聽起來很優雅，但根據我的經驗，沒有“瘦客戶端”解決方案帶來過更少的痛苦。

相信您的“邪惡”直覺。 有時它們是錯誤的，但是您仍然應該在早上考慮時考慮一下，因為通常它們是正確的。