乐胖代购免代理版

今回はWordBookの検索と削除についてです。

検索
- Search アクション
- List アクション
削除
- Delete アクション
- Exec_delete アクション
まとめ

検索

検索ではクライアントがサーバに正規表現を送り、マッチするデータをHTMLで送ってもらいます。送信方法がGETでもPOSTでもプログラムできますが、今回はGETを使うことにします。

GETでデータを送る場合はアドレスに続く?以後にデータを付け足す。このことから
- URLの長さの仕様上（理論上）の制限は無いようだが、ブラウザの実装上はあるらしい。そのためあまりに大きいデータ（目安として約8000、ただし古いブラウザでは約2000ということもあるらしい）を送るのには適していない
- URLに置かれるために暗号化できず、セキュリティ上問題がある（URLが暗号化されると行き先が分からなくなってしまうので、暗号化できない）
- URL上に置かれるので、ブックマーク時にデータも保存することができる。例えばGoogle検索では検索語句はURLに挿入されるので、ブックマークしておけば同一語の検索が簡単にできる
GETはそもそもリソースを要求するメソッドであることから、検索結果を送ってもらうメソッドとしては適している
POSTではTurboがリダイレクトを期待するのに対して、GETではリダイレクトの必要がない。これはRailsではアクションの節約になる

検索ワードを秘匿する必要はないので、上記を総合的に考えてGETメソッドを使うことにしました。特にリダイレクト無しで済むのは大きいような気がします。

Search アクション

ナビゲーションバーのSearchをクリックするとリンク先からsearchアクションにルーティングされます。

get 'words/search'

コントローラのsearchアクションの部分は次のようになっています。

def search
  @search_word = ""
end

@search_wordは検索枠の初期値で、最初は空文字列にしておきます。

ビュー（/app/views/search.html.erb）は次のようになっています。

<h1 class="my-2">単語検索</h1>
<%= form_with url: words_list_path, method: :get do |form| %>
  <div>
    <%= form.label :en, "英単語", class: "form-label" %><br>
    <%= form.text_field :en, value: @search_word, class: "form-control" %>
  </div>
  <div class="my-2">
    <%= form.submit "検索",  class: "btn btn-primary" %>
  </div>
<% end %>
</div>

タイトルは「単語検索」。もうおなじみのmy-2クラスは、m（マージン）y（上下）2（rem）で、上下に隙間を作るBootstrapのクラス
form_withメソッドにはモデルはつけない。 createやupdateと異なり、モデルの生成、改変を行わないからだ。アクセス先はword_list_pathメソッドの返り値/words/listである。 method: :getによって、GETメソッドでのデータ送信となる
「英単語」のラベルをつける
text_fieldメソッドによりtype="text"のinputタグを生成する。初期値は@search_wordで与えられるが、searchメソッドからの流れでは空白になっている。一度送信してエラーになった後の再入力では前回入力値が@search_wordに残っているので、それが初期値になる
サブミットボタンの文字は「検索」になる

検索画面は次のようになります。

例えば「cool」を検索枠に入力してサブミット・ボタンを押すと、次のようなURLに送信されます。

http://localhost:3000/words/list?en=cool&commit=%E6%A4%9C%E7%B4%A2

最後の%のついた6バイトデータは「検索」がURL用に変換されたものです。このように、GETメソッドでのデータ転送は、URLの?以後に「キー=データ」の形で行われます。

List アクション

GETで/words/list?... ... ...にアクセスすると、Wordコントローラのlistアクションにルーティングされます。

get 'words/list'

コントローラのlistアクションの部分は次のようになっています。

class WordsController < ApplicationController
... ... ...
... ... ...
  def list
    @search_word = params[:en]
    if @search_word == ""
      flash.now[:alert] = "検索ワードは入力必須です"
      render :search, status: :unprocessable_entity
    end
    begin
      pattern = Regexp.compile(@search_word)
    rescue RegexpError
      flash.now[:alert] = "正規表現に構文エラーがあります"
      render :search, status: :unprocessable_entity
    else
      @words = Word.all.select{|word| word[:en] =~ pattern}.sort{|w1,w2| w1[:en] <=> w2[:en]}
    end
  end
... ... ...
... ... ...
end

検索パターンはparams[:en]で手に入れることができる。 form_withでフォームタグを作ったときにモデルの指定がなかったことから、params[モデル名][en]の[モデル名]が無くなったことによる。検索パターンは@search_wordに代入する
検索パターンが空文字列だったときは、入力画面を再表示する。フラッシュ「検索ワードは入力必須です」を表示する。なお、検索パターンはRubyの正規表現に直されるのだが、仮に空文字列を正規表現にすると//になり、任意の文字列にマッチする。これを許す考え方もあると思う。その場合はこのif文は必要ない
検索パターン文字列を指す@search_wodから正規表現オブジェクトpatternを作る。 Regexp.compileメソッドを用いる。
コンパイルができない場合は例外が発生する（例えば検索ワードが「*」の場合。繰り返しを表す*の前に文字が必要）。例外をrescueで捕捉し、「正規表現に構文エラーがあります」をフラッシュにセットし、searchビューで入力画面を再描画する。 HTTPステータスはunprocessable_entity
例外が発生せず無事にコンパイルできた場合は、else節を実行する。 Word.allは、Wordクラスのオブジェクトをデータベースからすべて取り出し、それをActiveRecord::Relationクラスのオブジェクトにして返す。このクラスはEnumerableモジュールをインクルードしているので、selectなどのメソッドを使うことができる。 selectメソッドは、そのブロック（正規表現patternと一致する）が真となるWordオブジェクトの配列を返す。最後にその配列にsortメソッドを用いる。 sortメソッドはブロックによる大小評価（<=>メソッドと同じ評価基準）によりソートを行う。英単語の辞書順にデータがソートされる。このあと、listビューに@wordsが引き継がれ、マッチした単語の一覧をHTMLにして送信する。なお、リクエストがGETメソッドだったのでリダイレクトは不要

一度全部データを取り出してから正規表現でマッチするWordオブジェクトの配列を作っています。データベースから全部取り出さず、正規表現でマッチするものだけを取り出すことはできないのでしょうか？これは可能ですが、いくつか解決しなければならない問題があります。

Rails自身はデータ取り出し時の正規表現はサポートしていない（注：LIKE句は使える）
SQlite3がデフォルトでは正規表現をサポートしていない。 RailsからSQlite3に発行するSQLも正規表現は使えない。（注：コマンドラインから起動する「sqlite3」というコマンドは正規表現をサポートしている）
正規表現によるデータ取得に関するSQLの構文が統一されていない。データベースごとにRailsの発行するSQLを変えなければならない
仮にクライアントから送られてきたデータをSQLに単純に埋め込むとしたら、それは非常に危険（SQLインジェクション）。それを避けるには、データの内容をチェックする必要があり、そのためのプログラムを書かなければならない。今回はローカルでの使用を考えているので危険性は少ないが、これをネット上で一般公開する場合は特に考慮が必要

この問題はデータベースの大きさとアクセスの頻度によります。それらがさほど大きくなければ、データを全部読み出す負担は小さく押さえられます。逆に膨大なデータでは負担が増し、正規表現のSQLを発行するメリットが大きくなります。

単語帳のデータ数は通常さほど大きくないので「データ全読み出し」のデメリットはあまり現れないと思われます。データ数が極めて大きくなるような場合には変更を検討することが望ましいかもしれません。

削除

削除の流れは次のようになります。

ナビゲーションバーのDeleteをクリック
Wordコントローラのdeleteアクションが実行される＝＞削除画面表示、その中に削除単語を入力する枠がある
削除単語を入力してサブミットボタンをクリック
Wordコントローラのexec_deleteアクションが実行される＝＞削除実行、次の画面にリダイレクト

Delete アクション

ナビゲーションバーのDeleteをクリックすると/words/deleteにGETメソッドでアクセスします。これはWordコントローラのdeleteアクションにルーティングされます。

get 'words/delete'

deleteアクションは次の通りです。

def delete
  @delete_word = ""
end

@delete_wordはビューの中で入力枠の初期値として使われます。最初は空文字列です。

ビュー（/app/views/delete.html.erb）は次のようになります。

<h1 class="my-2">単語削除</h1>
<%= form_with url: words_exec_delete_path, method: :delete do |form| %>
  <div>
    <%= form.label :en, "英単語", class: "form-label" %><br>
    <%= form.text_field :en, value: @delete_word, class: "form-control" %>
  </div>
  <div class="my-2">
    <%= form.submit "削除",  class: "btn btn-primary", data: {turbo_confirm: "Are you sure?"} %>
  </div>
<% end %>

今までのフォーム作成と大きく違うのは次の2点です。

リクエストのメソッドがDELETEになっている。
サブミットボタンにdata: {turbo_confirm: "Are you sure?"}がついている。これはボタンをクリックしたときに確認ダイアログを表示するためのものです。 Rails7ではTurboが使われているのでturbo_confirmにしなければなりません。（以前はconfirmでした）

送信先のアドレスはwords_exec_delete_pathメソッドの返り値である/words/exec_deleteになります。

Exec_delete アクション

DELETEメソッドで/words/exec_deleteに送られたリクエストはWordsクラスのexec_deleteアクションにルーティングされます。

delete 'words/exec_delete'

exec_deleteアクションは次の通りです。

def exec_delete
  @delete_word = params[:en]
  @word = Word.find_by(en: @delete_word)
  if @word == nil
    flash.now[:alert] = "単語#{@en}は未登録のため削除できません"
    render :delete, status: :unprocessable_entity
  else
    begin
      @word.destroy
    rescue
      flash[:alert] = "単語#{@en}を削除できませんでした"
    else
      flash[:success] = "単語を削除しました"
    end
    redirect_to words_index_path, status: :see_other
  end
end

クライアントから送られたデータを@delete_wordに代入する
データベースから@delete_wordに一致するデータを取り出す
データが見つからなければ@wordはnilになる。このとき「単語・・・は未登録のため削除できません」をフラッシュに入れてdeleteビューを再送信する。このとき、@delete_wordすなわちクライアントが削除を要求した単語名が入力フォームの初期値になる。ステータスはunprocessable_entityとする
データが見つかったときは@word.destroyメソッドでデータベースから削除する。
エラーが発生したときは「単語・・・を削除できませんでした」をフラッシュにセットし、Wordsコントローラのindexアクションにリダイレクト
エラー無く削除できた場合は「単語を削除しました」をフラッシュにセットし、Wordsコントローラのindexアクションにリダイレクト

リダイレクトのときのHTTPステータスコードは303（see other）です。 status: :see_otherを省略すると、デフォルトの302（Found）になります。この2つのステータスコードに対するブラウザの動作は

302（Found）同じHTTPメソッドで新しいURLにアクセスする。つまり「はじめのアドレスが（一時的に）移転しているのでそちらにリダイレクトせよ」というのが302の趣旨であるので、同じHTTPメソッドでアクセスする。（ただし、歴史的理由でGETメソッドでリダイレクト先にアクセスするブラウザもある）
303（see other）GETメソッドで新しいURLにアクセスする。これは「主にPOSTでデータを送信した後に受信するリソースをリダイレクト先に用意してあるのでそちらを見よ」という趣旨なので（リソース回収用の）GETでリダイレクト先にアクセスする

そのため、302リダイレクトを使うとDELETEメソッドでリダイレクト先にアクセスされ、最悪の場合には何らかのリソースが削除される可能性があるそうです。ネットではそのような悲しいできごとに遭遇した人からの注意喚起が見られます。気をつけましょう。

まとめ

以上でとりあえず動くWordbookができあがりました。

Railsは動的なウェブを作ることが特徴です。「動的」とは、リクエストを受け取ったサーバーがリクエストに応じたHTML文書をその場で作成して送ることです。それに対して「静的」とは、あらかじめHTML文書をサーバー内の用意し、リクエストのアドレスに対応する文書を送ることです。「静的」なウェブに対してPOSTでデータを送ることは意味がありません。

Railsのポイントのひとつは、POSTなどで送られるデータの処理になります。前回と今回の記事でその処理の流れがお分かりいただけたのではないでしょうか。例えば、appendでは

appendアクション：入力画面を送信する
createアクション：送られてきたデータの処理。正常＝＞303リダイレクト。エラー：unprocessable_entityステータスで入力画面を再送信

という流れです。

GETでデータを送る場合は、処理が正常だった場合のリダイレクトがありません。そこだけが違いです。

おもこん

おもこんは「思いつくままにコンピュターの話し」の省略形です

徒然Ruby（３０）Rails7 検索と削除

検索

Search アクション

List アクション

削除

Delete アクション

Exec_delete アクション

まとめ