Как избежать дублирования в имени параметра

ProgramBox

Как избежать дублирования в имени параметра

Post author:admin
Запись опубликована:12 апреля, 2023
Post category:Вопросы по программированию

#java #jsp #parameters

#java #jsp #параметры

Вопрос:

Внутри СООБЩЕНИЯ в .jsp файле я бы хотел сделать что-то вроде этого:

 <input type="text" name="...">

И внутри сервлета я хотел бы сделать:

 request.getParameter(...)

Теперь, где и как я должен объявить «…», чтобы я мог избежать дублирования и повторно использовать одну и ту же строку.

Должно ли это выполняться в интерфейсе, подобном этому:

общедоступный интерфейс, ПОЭТОМУ {

 String POST_PARAM = "userinput";

}

Или в файле свойств? Или …?

В любом случае, как мне затем получить к этому доступ из .jsp и из файла .java?

Ответ №1:

Вы можете определить константы, подобные final String POST_PARAM = "userinput"; , а затем использовать их в разметке: <input type="text" name="<%=POST_PARAM%>"> . Перемещение имен полей в файл свойств не кажется выгодным, если у вас нет причин для этого.

Чтобы получить значение параметра из HTTP-запроса, вызванного отправкой формы, скажите request.getParameter(POST_PARAM) .

Я надеюсь, что это поможет.

1. 1 спасибо… но где я должен определить эту константу? В интерфейсе? В сервлете? Я пытался определить его в интерфейсе, но тогда я не смог ссылаться на него из .jsp: я пробовал *<%=Build. POST_PARAM%> но это не сработало.

2. @CedricMartin Вы на правильном пути. Я подозреваю, что это не сработало, потому что вы не импортировали интерфейс сборки внутри JSP. Вам нужно импортировать интерфейс вверху в JSP точно так же, как вы делаете в обычном классе Java. <%@ page import=»Build» %>

3. Вы можете определить его везде, но поскольку предпочтительнее реализовывать java-код в классах Java и избегать сценариев в JSP, рекомендуется создать отдельный интерфейс / класс / перечисление, который определяет все необходимые константы.

4. Нет, использование <%=POST_PARAM%> не подходит для этой цели. Почему вы не используете технологию JavaBeans и стандартные действия, такие как setProperty

Ответ №2:

Вы могли бы получить … из компонента с использованием EL. Однако для меня это необычно.

Ответ №3:

Вы можете использовать стандартные действия: jsp:useBean, jsp:setProperty и технологию JavaBean:

Пример:

A.jsp следует вызвать HTTP POST для B.jsp . B.jsp должно автоматически отображать все поля и перенаправлять на ваш сервлет.

 // model.MyBean.java
class MyBean {
   private int age;
   // gettersamp;setters
}

// A.jsp:
<form method="POST" action="B.jsp">
   <input type="text" name="age">
</form>

// B.jsp
<jsp:useBean id="form" class="model.MyBean" scope="request" />
<jsp:setProperty name="form" property="*" />
<jsp:include page="/servletURL" />

Небольшое описание:

Будет создан класс MyBean. Этот компонент должен иметь точно такое же имя полей, как имя в вашей форме: для <input type="text" name="age"> в компоненте должно существовать int age поле и средство получения / установки.
jsp:setProperty с помощью подстановочного знака все значения из формы A.jsp автоматически преобразуются в ваш компонент.
если вы хотите вызвать свой сервлет, вы можете просто включить соответствующий URL. Затем в сервлете у вас будет доступ к атрибуту запроса «форма», который будет иметь MyBean с введенными значениями.

1. это довольно многословно. Я мог бы как-то согласиться с вами, но сейчас 2011 год, и вы действительно предлагаете использовать изменяемые объекты? Например, компоненты с установщиками? Нет. В настоящее время я склоняюсь к более функциональному подходу (и, кстати, в конечном итоге могу вообще отказаться от Java ; ) Мне не нравятся изменяемые материалы. Я думаю, что сам факт, что beans заставляет вас использовать установщики, полностью нарушен и является достаточно веской причиной для отказа от Java в целом 😉 Я понимаю, что кто-то в Sun, возможно, решил, что это «единственный святой способ сделать это» , но те же люди также думали, что изменчивость — это хорошо, что заставляет меня задуматься 🙂

2. да, у нас есть 2011, это означает, что мы не используем скриптлет <% %> и выражение <%= %> — EL expression ваш друг. Я не понимаю, почему мы не должны использовать изменяемый объект в 2011 году.