JSTL и Javascript

Question

Имеет ли тег внутри тега jstl плохую форму? Так, например, я знаю, что следующее будет работать, но считается ли плохой формой наличие тегов script внутри моих тегов jstl в моем jsp?

<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's $ (document) .ready (), например ) для принудительного применения. аккуратное разделение, и сделать вашу жизнь намного проще.

Answer 2

Я так не думаю - это то, как вы условно делаете вещи в JSTL, я не думаю, что у вас должен быть тег script, чтобы иметь его.

Answer 3

Я сейчас имею дело с некоторыми большими гигантскими термами JSTL в пуншбоу, поэтому я решил добавить в микс какую-нибудь перспективу разработки пользовательского интерфейса.

SGM-подобный синтаксис, заключающий в себе другой домен SGM-подобного синтаксиса, вообще ужасная форма, но это не твоя вина. Вы можете помочь сделать это лучше, оставив их разделенными как бы то ни было. Это не всегда возможно, но чем больше вы можете устанавливать переменные и помещать их в HTML только в случае необходимости, тем лучше.

Другая проблема заключается в том, что вы пытаетесь настроить клиентские сценарии непосредственно с помощью серверного кода, и я бы сказал, что да, учитывая мой пятилетний опыт работы с кодом пользовательского интерфейса, это большой гигантский PITA для вашего Люди UI внезапно сталкиваются с триггерами, они на самом деле не знают, как вернуться к источнику и не имеют никакого контроля над ними. Черт, запускает то, что даже разработчики Java не обязательно уверены, как вернуться к источнику, если все достаточно уродливо.

Представь, что мы на месте. Возьмем сервис-ориентированную архитектуру, но давайте добавим Java-строки в набор параметров, которые позволят нам фактически устанавливать вызовы объектных методов со стороны клиента. Это хорошая идея? Нет, это ужасная идея. Не потому, что вы не хотите, чтобы разработчики JavaScript писали на Java (вы не хотите - это делает нас действительно неприятными), а потому, что в этих двух точках разделения все должно быть как можно проще. Я отправляю вам данные, вы можете обращаться с ними так, как хотите.

Так что просто передайте нам данные. В идеале в форме JSON, но мы будем мириться с чем угодно, чтобы сервер не определял выполнение JS. Последнее, что вы хотите, это паническое бегство копыт пользовательского интерфейса на ваших пастбищах, заполненных бобами-убийцами, так что не заставляйте нас искать то, что дерьмо тесно связано между точками по обе стороны стены HTTP, без причины когда-либо имел смысл для меня. Мы оборачиваем сообщения вокруг камней и бросаем их через стену. Это звучит не элегантно, но ни одно из решений для «тонкого клиента» в моем опыте никогда не вызывало меньше боли.

Доверяй своим инстинктам "Ик". Иногда они ошибаются, но вы должны выяснить это в душе утром, когда вы все еще думаете об этом, потому что обычно они правы.