0

アクションが呼び出されたときに、期待されるパラメーターが指定されていることを確認しようとしています（ユーザープロファイルを表示するなど、パラメーターにユーザーIDが含まれていることを確認したい：viewUser.action？userId = 1は正常に機能するはずですが、viewUser.actionはエラーページにリダイレクト）

そこで、userIdフィールドをnullにできないことを指定する検証xmlを作成しました。すべてが正常に動作します。

しかし今、prepare（）で、userIdを使用していくつかの事前作業を行います。実際には、prepareinterceptorは検証インターセプターの前に呼び出されるため、userIdがnullの場合、nullPointerExceptionが発生し、エラーが以前に発生したため、検証は呼び出されません。インターセプターの順序を切り替えることができることは知っていますが、切り替えたくありません。

だから私の質問は：私はprepare（）メソッド内でパラメータを使用することになっていますか？それを処理する他の方法はありますか？

私の悪い英語をありがとうそして申し訳ありません:(

4

3 に答える 3

1

「paramsPrepareParamsStack」インターセプタースタックを使用します。

于 2012-04-27T09:14:43.963 に答える
0

以下は、この問題を回避し、すべての開発を容易にする方法についての説明ですが、最も直接的な解決策は間違いなくDavesです。私は間違いなくそれを最初に実装し、問題を解決し、将来的には以下を使用します。

私の経験では、prepare（）は、依存性注入（Spring）によって最適に提供されるジョブをアクションに実行させるサービスを取得するために使用されます。

通常、アクションクラスは次のことを担当します。

  • アクションを実行するために必要なオブジェクト（サービスオブジェクト）を取得します。
  • アクションを実行するために必要なパラメーターを取得します（必要なものを取得するためにサービスオブジェクトによって使用されます）。
  • パラメータの検証が理にかなっています（検証メソッド/アノテーション、xmlに外部化できます）。
  • アクションの実行（前述のサービスオブジェクトを使用）。
  • ビューに必要なオブジェクトを取得しています...

これはあなたが知っていることであり、prepareはアクションを実行するために必要なオブジェクトを取得することでもあります（DB接続を開くなどのことを行う人もいますが、理想的にはオブジェクトをサービスします）。実際の実行は、executeメソッドに制限する必要があります。

選択したDIプロバイダー（Spring / Guice）で注入されたサービスオブジェクトを使用する理想的なルートを使用すると、prepareメソッドを必要とする理由がほとんどまたはまったくないことがわかります。その結果、私たちの行動はより小さくなり、理解しやすくなり、テストしやすくなります。

于 2012-04-28T21:40:54.920 に答える
0

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>

しかし、私はこの考えが好きではありません。より良い方法は、アクションロジックを変更し、いくつかのパラメーターを使用している場合は、コードのすべての部分を準備関数から削除することです。なぜあなたは「準備」でそれをするのですか？検証中に結果を使用しますか？

于 2012-04-27T10:11:52.913 に答える