struts2 подготовка и проверка

Я пытаюсь гарантировать, что при вызове действия будут заданы ожидаемые параметры (например, чтобы показать профиль пользователя, я хочу быть уверенным, что параметры содержат идентификатор пользователя: viewUser.action?userId=1 должен работать хорошо, но viewUser.action должен перенаправить на страницу с ошибкой)

Поэтому я создал XML-файл проверки, в котором указано, что поле userId не может быть нулевым. Все работает нормально.

Но теперь при подготовке() я выполняю некоторую предварительную работу, используя идентификатор пользователя. Дело в том, что перехватчик подготовки вызывается перед перехватчиком проверки, поэтому, если userId равен нулю, у меня есть хорошее исключение nullPointerException, и проверка не вызывается, потому что ошибка произошла раньше. Я знаю, что могу изменить порядок перехватчиков, но не хочу.

Итак, мой вопрос: я должен использовать параметры внутри методов prepare()? Есть ли другой способ справиться с этим?

Спасибо и извините за мой плохой английский :(


person Estragon    schedule 27.04.2012    source источник


Ответы (3)


Используйте стек перехватчика paramsPrepareParamsStack.

person Dave Newton    schedule 27.04.2012
comment
Так что у меня будет params =› prepare =› params =› validation. Но у меня все еще будет проблема с использованием idUser при подготовке, если он равен нулю. - person Estragon; 27.04.2012
comment
@Estragon Вы не можете проверить, является ли оно нулевым? Или ваша бизнес-логика, которая использует его, не выполняет никаких проверок работоспособности? - person Dave Newton; 27.04.2012
comment
Конечно, я проверяю все входные данные, но я не считаю, что подготовка - это место для проверки, и система проверки должна быть лучше, чем ручная проверка в функциях подготовки / бизнеса... Также я действительно не знаю, как реагировать, если параметры в подготовке равны нулю - person Estragon; 27.04.2012
comment
@Estragon Итак, вы не хотите менять порядок перехватчиков и не хотите проверять вручную. Похоже, вам не повезло. - person Dave Newton; 27.04.2012
comment
Ну, другой его выбор - изменить то, как он думает о проблеме, поэтому paramsPrepareParamsStack не нужен, это может быть полезно знать, но это самый долгий путь. - person Quaternion; 29.04.2012
comment
@Quaternion Это необходимо, если вы не хотите получать параметр из запроса вручную. - person Dave Newton; 29.04.2012
comment
@DaveNewton хорошо, я имел в виду изменение его мышления, чтобы методы обслуживания не нуждались в инициализации с параметрами в его действии ... так что измените его мышление о проблеме, чтобы сделать все более элегантным. Выкопать параметры из запроса, безусловно, является еще одним вариантом, хотя он и побеждает Struts2 и любой смысл аскетов. - person Quaternion; 29.04.2012
comment
@Кватернион О. У меня нет проблем с использованием параметров в подготовке; просто зависит от потребностей. Я не делал этого много, но иногда это очень удобно. - person Dave Newton; 29.04.2012

Вы можете изменить порядок перехватчиков по умолчанию в файле struts-default.xml, чтобы перехватчики флажков и параметров запускались до подготовки перехватчика.

<interceptor-stack name="basicStack">
  <interceptor-ref name="exception"/>
  <interceptor-ref name="servletConfig"/>
  <interceptor-ref name="checkbox"/>
  <interceptor-ref name="params"/>
  <interceptor-ref name="prepare"/>
  <interceptor-ref name="conversionError"/>
</interceptor-stack>

Но мне не нравится эта идея. Я считаю, что лучше всего изменить логику действий и удалить все части кода из функции подготовки, если они используют некоторые параметры. Почему вы делаете это в «подготовке»? Вы хотите использовать результаты во время проверки?

person Vasily Komarov    schedule 27.04.2012
comment
Для этой цели уже существует prepareParamsPrepareStack; зачем делать самому? Кроме того, ОП уже заявил, что переключение порядка перехватчиков нежелательно по какой-либо причине. - person Dave Newton; 27.04.2012
comment
Ах, вы имеете в виду paramsPrepareParamsStack? Да, это лучшее решение. - person Vasily Komarov; 27.04.2012
comment
Ой, да - я получил их задом наперед, я, должно быть, забыл за прошедшие 30 минут;) - person Dave Newton; 27.04.2012
comment
@Estragon Также я не знаю, как реагировать, если параметры при подготовке равны нулю. 1. На этот раз используйте функцию проверки в своем действии, а не validation.xml. 2. Удалите всю логику с idUser из подготовки к проверке (если вы хотите выполнить ее до выполнения такой машины). 3 Если вы обнаружите проблему с простой проверкой idUser, используйте addFieldError(idUser, сообщение об ошибке idUser) - person Vasily Komarov; 27.04.2012

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

По моему опыту, prepare() используется для получения услуг, которые позволят действию выполнять свою работу, что лучше всего обслуживается внедрением зависимостей (Spring).

Обычно класс действия отвечает за следующее:

  • Получение объектов, необходимых для выполнения действия (служебных объектов).
  • Получение параметров, необходимых для выполнения действия (используемых служебными объектами для получения того, что нам нужно).
  • Проверка параметров имеет смысл (метод проверки/аннотации можно преобразовать в xml).
  • Выполнение действия (с использованием ранее упомянутых сервисных объектов).
  • Получение объектов, необходимых для просмотра...

Это вы знаете, и вы также знаете, что подготовка связана с получением объектов, необходимых для выполнения действия (в идеале служебных объектов, хотя некоторые люди делают такие вещи, как открытие соединений с БД). Фактические действия должны быть ограничены методом execute.

Следуя идеальному маршруту, который использует сервисные объекты, внедренные выбранным вами поставщиком DI (Spring/Guice), мы обнаруживаем, что у нас практически нет причин вообще нуждаться в методе подготовки. В результате наши действия становятся меньше, их легче понять и легче тестировать.

person Quaternion    schedule 28.04.2012