Почему EL-функции должны быть из методов Java с не возвращаемыми типами возврата?

У меня есть ситуация, в которой я думаю, что это хорошая идея, чтобы использовать функцию EL, которая является пустым Java-методом. Это простой jsp для обновления базы данных имени и фамилии людей. Итак, есть два текстовых поля: имя и пароль. Пользователь вводит их и нажимает кнопку "Отправить", а затем перенаправляет их с помощью POST в другой jsp. Этот jsp просто вызывает функцию EL, давайте назовем ее "put", которая принимает два параметра и является производной от метода Java putPerson(String, String) который получает соединение с базой данных и помещает имя и фамилию на свои места. Сейчас, putPerson является недействительным, потому что все, что он делает, это помещает строки в базу данных. Итак, это плохая практика программирования, и если да, то почему? Мне кажется, это быстрое и элегантное решение, и оно работает. Единственная проблема в том, что вы не можете просто позвонить, сказав ${put(first, last)} потому что это выводит "<" по какой-то причине, но это достаточно легко обойти. Так почему же они рекомендуют не использовать функции EL с типами возвращаемых пустот?

2 ответа

Решение

Печать < будет приходить откуда-то еще, или это ошибка в парсере EL. Но в любом случае, вы не должны делать это в функции EL.

EL-функции предназначены для утилит - например, .substring(), .join() (массивы) и т. д. И они используются во время отображения страницы и нуждаются в более сложной логике представления.

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

Механизм, который вам нужен, старше, чем EL, и он называется скриптлетом:

<%
    whatever.putPerson("John", "Smith");
%>

В ранних версиях JSP для вывода значений использовался другой синтаксис (обратите внимание на знак равенства):

<%=
    whatever.getVal();
%>

Поскольку считалось, что легче поддерживать код при наличии разделения команды / запроса, EL был введен как способ запроса модели (= чтение свойств bean-компонентов). Поскольку скриптлеты были доступны для удовлетворения редких случаев, когда просто "запускать некоторый код" было бы необходимо, добавление такой функциональности в EL не имело бы смысла: у нас было бы два способа достичь того же самого, и мы бы нарушили концепцию EL выражения всегда имеют значение и тип.

Так:

  • использование EL для вызова методов void похоже на... uhmpf... использование импорта для запуска кода: это не имеет смысла;
  • это не проблема, так как вы можете использовать тот самый механизм, который был создан для вызова методов: скриптлет.
Другие вопросы по тегам