JSTL和Javascript

jstl標籤內部的標籤是否被認爲是不良格式？因此，舉例來說，我知道以下方法可行，但是在我的jsp的jstl標籤中使用腳本標籤被認爲是不好的形式？JSTL和Javascript

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

來源

2009-07-08 codemonkeyww

我不知道不好的形式（有點苛刻），但你可能會考慮到的人而不JS查看網頁啓用您的<c:otherwise>將有效輸出什麼，這不是很優雅。另外，如果頁面是遞增呈現的，那麼您的函數調用可能會在輸出時執行，並且在DOM完全被瀏覽器加載之前執行，因此表現得不可預知（或者根本不工作 - 我已經這發生）。

我會考慮把所有的函數調用放在頭部，並使用衆多可用的技巧之一來檢測DOM何時加載（jQuery's $(document).ready() for example）以實現更加整潔的分離，並讓您的生活變得更加輕鬆。

來源

2009-07-09 00:00:45 karim79

我不這麼認爲 - 這是你如何有條件地做事JSTL，我不認爲你應該有一個腳本標籤只是爲了有一個。

來源

2009-07-08 22:46:41 stevedbrown

我現在正在處理punchbowl中的一些大型JSTL terds，所以我想我會將一些UI開發人員的視角放入組合中。

類似SGM的語法包裝類似SGM的語法的另一個領域是糟糕的形式，通常這不是你的錯。你可以通過保持它們分離來幫助改善它。這並非總是可行，但只有在必要時纔可以設置變量並將其放入HTML中，效果會更好。

另一個問題是你試圖直接用服務器端代碼引發客戶端腳本，並且由於我有5年處理UI代碼的經驗，我會說是，它是一個巨大的PITA for你的UI人突然遇到觸發器，他們並不真正知道如何追溯到原點，並且沒有任何控制權。地獄，觸發，即使Java開發人員不一定確定如果事情足夠醜陋如何追溯到原點。

想象一下我們的鞋子。採用服務驅動架構，但讓我們將Java字符串添加到param組合中，讓我們可以從客戶端實際建立對象方法調用。這是一個好主意嗎？不，這是一個可怕的想法。不是因爲你不想讓JavaScript開發人員編寫Java（你不這麼做 - 它使我們感到非常不愉快），而是因爲在這兩個分離點上，事情應該儘可能簡單。我向你發送數據，你可以根據需要處理它。

所以，只需提交我們的數據。理想情況下使用JSON形式，但我們會忍受任何事情來阻止服務器確定JS執行。你最不希望發生的事情是在你的面向OOP的謀殺bean的牧場中踩踏蹄子，所以不要強迫我們去尋找那些沒有理由的東西在HTTP牆的任何一側上的點之間緊縛的垃圾。對我來說很有意義。我們把信息包裹在岩石周圍，然後在牆上夾住。這聽起來很不起眼，但根據我的經驗，「瘦客戶端」解決方案沒有造成任何痛苦。

相信你的「ick」本能。有時候他們錯了，但是當你還在想這件事的時候，你應該在早上洗澡時弄清楚，因爲通常他們是對的。

來源

2012-12-12 03:47:31

JSTL和Javascript

回答

相關問題