0

ファイルのアップロードが成功すると、リクエストは彼のホームページに転送されます。これは、ファイルをアップロードした場所と同じページです。アップロードが成功した場合、リクエストを転送する前に、「はい、ファイルは正常にアップロードされました!」という属性が設定されます。

ユーザーのホームページで次のコードが実行され、アップロードの試行が成功したことをユーザーに通知する必要があるかどうかを確認します。ユーザーが警告ボックスの形式で成功メッセージを一度見た場合、次回は別のファイルを正常にアップロードしたときに成功メッセージが表示されるはずです。しかし、ページをリロード/リフレッシュする際の最初の試行の後、要求リストから属性を削除した場合でも、アップロードの試行が成功したことをユーザーに通知する警告ボックスが再び表示されます。

ファイルのアップロード試行が成功した後にユーザーに成功メッセージを表示するスニペット

<script>
        window.onload = function() {
        <% message = (String)request.getAttribute("SuccessMessage");
           AttemptToUploadFile = (Boolean)request.getAttribute("UploadAttempt");
           request.removeAttribute("SuccessMessage"); // Remove the attribute so that alert box doesn't pop every time the page is refreshed
              if(message != null) {%>
                      alert("File successfully uploaded !");
                          <% } %>

        }
    </script>

特定の属性を削除しても、警告ボックスが何度も表示されるのはなぜですか?

4

4 に答える 4

3

HTTPがどのように機能するか、および「サーバー側」と「クライアント側」の概念について、どこかで概念的な誤解があります。

特定のHTTPリクエストに関連付けられたHTTPレスポンスが、レスポンスの本文（この場合、JSPで生成されたHTMLソースコード）をクライアント側に送信するジョブを終了するたびに、リクエスト属性はすでにゴミ箱に入れられています。

ブラウザでページを更新/再読み込みすると（データが再送信されるというブラウザの警告を無視して！）、元のHTTPリクエストデータがサーバーに再送信されるため、サーバーはHTTPリクエスト全体をもう一度処理して設定します。もう一度属性をリクエストしてください。属性を明示的に削除しても、それは解決されず、それ自体ではまったく意味がありません。

機能要件が何であるかわかりません。エンドユーザーがアップロードされたファイルをもう一度再送信できるようにしますか？メッセージをもう一度表示しないのはなぜですか？エンドユーザーは、そもそも間違っているファイルをもう一度再送信しようとしていることを警告されるべきではありませんか？その場合、ディスク上にすでに保存されているファイル、またはセッションスコープ内のマップに基づいてファイル名を検証するメソッドに追加のチェックを追加しdoPost()、要求を無視して例外をスローするか、別のメッセージを表示します。

String filenameOfUploadedFile = getItSomehow();

if (isAlreadyUploaded(filenameOfUploadedFile)) {
    request.setAttribute("message", "Error, the file is already uploaded!");
}
else {
    // Process.
    // ...

    request.setAttribute("message", "File upload is successfully processed!");
}

次に、JSPコードを次のように簡略化できます。

<script>
    <c:if test="${not empty message}">
        window.onload = function() {
            alert('${message}');
        }
    </c:if>
</script>

（私は個人的に90年代のスタイルのアラートによるフィードバックを与える方法に同意しませんが）

于 2012-04-25T15:15:10.447 に答える
0

たぶん、メッセージはその後のページの読み込みでまだnullではありません。おそらく、メッセージが未定義か何か他のものであるかどうかをチェックする必要があります。デバッガーを調べて、メッセージの値を確認しましたか？Firebugはこれに適しています。

于 2012-04-25T09:37:17.307 に答える
0

メッセージはリクエストレベルです。したがって、jspのremoveAttributeは何も実行しておらず、リロード/リフレッシュするたびにメッセージが再表示されます。これは、更新/再読み込みするたびに、新しいリクエストが作成されるためです。

コントローラ側でuがメッセージを設定している場所を正確に確認し、そこにロジックを処理する必要があります。

于 2012-04-25T09:57:13.540 に答える
0

ページを更新すると、サーブレットが再度呼び出されて属性が再作成されると思われるため、クライアント側でリクエストを変更しても意味がありません。

サーバー側で (フラグなどを使用して) 属性を削除し、JSP で要求オブジェクトを変更しないようにする必要があります。

于 2012-04-25T10:20:30.257 に答える