キャラ数が増えてきて、特定条件での絞込がしたいものの、例えば「特定バフの付与」だと、あまりにも候補が多すぎて絞り込めない。(例えば、今回のアーサーの「感電Lv」が他に誰が持ってたか？とか、ユエル達の「狐火」とかも)
となると、奥義やアビの説明文から自由検索をしたいと思うのは至極当然ではなかろうか？
やるとしたらどうするか。
SQLは別に問題ない。後SQLインジェクションとかサニタイジングなど入力欄を設ける事で考えなくてはいけない事があるので、それの対策が一番必要となる。それさえクリアできれば、後は仕様をどうするかにかかってる。
入力項目として、テキスト(日/英)欄。絞込条件は他の条件と同じで良いだろう。検索条件とテキストはandまたはorで両方有効にすべきか、自由検索を選択したなら他の条件は無効にするかは要検討。
画面にテキストフィールドを追加し、プルダウンのブロックとラジオボタンで活性/非活性を切り替えて、どちらか一つしか有効としないのが一番楽だとは思う。
日本語は「日本語情報」、英語は「英語情報」に分けるべきか、ここも要検討。
検索結果は、従来通りの表示で良いが、日英一緒に検索すると、日本語には無い単語でHitしたデータも表示されてしまう。その場合、検索結果やキャラを表示させても指定した単語は表示されない事になる。と考えると、日本語画面では日本語データ、英語画面では英語データのみを検索対象とするのが自然なように思える。
検索結果に該当部分の単語を含む、前後数文字を表示させるのも手だが…、検索結果画面までいじらないといけなくなるので、それは当面考えないことにしたい。
検索は２文字以上とするとして、単語以外のものをどうするか…と言っても、弾くのは現実的に難しい。かと言って候補を出すのも難しいだろうな…。リアルタイムで候補を抽出しプルダウン表示させるのもアリだろうけど、それをやった時のレスポンスやサーバー負荷が心配なので、最初は考えない事にしたい。(試してはみたいが)
文字数の最大値も考える必要がある。何文字が最適か。
また、空白を許可して複数の単語で検索するというのもあった方が良さそうではある。そうすると、単語をorかandで検索するオプションも必要になるだろう。それに応じて文字数の最大値も考慮する必要がありそう。
現状のstatテーブルは、検索条件をカウントしているが、自由テキストで検索条件をカウントすべきかどうか。検索対象のキャラやアビはカウントされるので特に変更はしなくてよい。条件をどうするか…だけ。statテーブルはどうせ俺しか見れないものだし、特に凝る必然性があるとも思わない。それに、自由文字列の場合は文字が一意に絞り込めるとは思えないので、レコードばかり増える懸念がある。
ただ…、どういうトレンドで検索しているのか…は把握できるのであった方が良いかもしれない。現状の利用数なら別にレコードが多少増えようが問題ないし、将来オフにすればいいだけだから、データ収集しておく方がいいかもしれない。要検討。
思い立った時にやるのが吉だろうから、近々仕様を決めて手を付けたい。
検索そのものはうまくできた。CONCATとLIKEだけでほぼほぼ無改造でできたし、絞込もちゃんと機能してる。
日/英、サニタイジング、AND/ORや最小文字数などをやらないといけないけど、大まかなロジックはこれでいけそう。
効果と自由検索は排他にすべきと思うので、それも考慮が必要だろうと思う。
次の段階として、大文字/小文字/半角/全角についてどうするかを検討する。単純にやるなら正規表現とか使わないと難しいとは思うけど、どうやるのが一番なのかな…。
正規表現では「AND」結合はうまく表現できないので使用は断念。力業でWHERE句のLIKE文を単語数分生成する事にした。
AND/ORや半角/全角スペースもうまくできた。
ただ、ちょっと検索に時間かかってるな…。「検索中…」表示とか欲しいかもしれない。CSSとかで色々できた気がするので、そこは調べてみよう。
次はエラー系(最小文字数と最大値関係)かな。
比較は単純にLIKEでやったけど、REGEXPを複数行使う事で、大文字/小文字/半角/全角をデータ弄らずにできないかな？ちょっと調べてみよう。
> 比較は単純にLIKEでやったけど、REGEXPを複数行使う事で、大文字/小文字/半角/全角をデータ弄らずにできないかな？ちょっと調べてみよう。
正規表現どころか、SQLだけでできちゃった。
COLLATE utf8_unicode_ci
これで全角/半角/大文字/小文字/かな/カナ…のぜ～んぶが解決しちゃった…。
(ただ、濁音、半濁音も区別されなくなっちゃうが、それはいいだろう)
文字数(最大６４文字)、単語数(５個まで)、単語長(２文字以上)、半角特殊文字(“％”以外)のチェックは完了。
半角特殊文字を除外したお陰で、SQLインジェクションも対応できたと思う。後はまぁテスト次第だけど…多分大丈夫w
入力文字のチェックは全部JavaScript側で実施。エラーが増えたので、エラー表示の方法を考え直す方が良さそう…かも。入力文字は消えない方がいいのは当然だけど、検索結果は残しておいた方がいいのかな…。(チェックが通って通信始める段階で消える)
ただ、連続でエラーが出た場合、エラーが変わったのか止まってるのかがわからないかもしれない。エラー発生後、テキストに何か入力するまで、背景色をピンクにするとかの工夫が必要かも。
文字列分割などで、RegExpオブジェクトを使ったが、これはlastIndexを直接弄るか、インスタンスを再度作り直さないと前回の位置からtest()がスタートしてしまう。逆にうまく使えば置換などが楽にできるけど今回は関係ない。
(正規表現の使い方としてはスタンダードだったが忘れてたよ)
後、末尾(先頭もだろうけど)空白は、trim()で取り除いておく必要がある。(そうしないと、分割した場合に単語として残っちゃう)
PHP側ではしなくても上手くいってるっぽいが、何が違うんかな？
(Ajaxのパラメタとして渡す際に削除されてるかも？)
エラー回り完了。
エラー時にフィールドの背景色を変えて、エラーが起きたことを明示できるようにした。ただ、フィールド(というかform)に、オートコンプリートをONにしておくと、サジェスチョンから選ぶと背景色が強制的に変わってしまい、bgcolorを指定しても変わらなくなってしまう。今のところ、一番簡単なのはオートコンプリートをオフにすること()
利便性とのトレードオフだけど、解決方法が見つかるまではこれで逃げよう。
エラーでフィールド背景色を変えた後、何か入力する事で解除(元の色)に戻すのもできた。これでエラー回りはメッセージ以外は完了。
エラーメッセージも完了
CONCATの仕様上、NULLがあると結合した後のデータはNULL扱いになってしまうので、CONCAT_WSに変えてみた所、今度は効果の数だけ全部Hitしてしまうようになってしまった。
GROUP BYを有効にすれば良いのだけれど、フリーテキスト検索時は強制的にONにしてしまおうか？
でも、それだとLv違いとかの為に入れてるのが意味をなさなくなる。
効果(effect_id)の数だけ出るわけでも無いようなので、もう少し調べてみるべきかもしれない。
JOINした行のうち、詳細TBLの注釈部分の文字列がHitした場合と、概要TBLにHitした場合で件数が異なっていた。
(当たり前だなw)
なので、やはりGROUP BYを複数カラムにして対処する事にした。
通常時もGROUP BYを有効にし(ただし、ab_noも含める)、指定があった時は１Lv上で絞り込むようにした。
しかし、今度はcountが上手くいかなくなったので、検索前の件数確認(count)と、実検索は別の値を使うように変更。
ひとまずこれで解決したと思う。
やっぱり「ひとまず」でしかなかったw
GROUP BYを指定するとCOUNTは、まとまった行が何行あるかを返してしまう。そのせいでカウント数は50件未満なのに、実際に検索すると50件以上になってしまうケースが多発w
という事で、もう一度カウントの辺りを見直した。
本来であれば、
SELECT COUNT(*) FROM (
SELECT * FROM … GROUP BY ab_id
)
のような形式で、いったんアビIDで行をまとめ、その結果の行数をカウントするのがスジなんだろうと思う。
ただ、そもそもカウントしたい理由は、大量データを一度に検索させると時間もかかるし、事前に件数を絞りたかったから。なのでサブQueryとかにするのは本末転倒な気がした。
という事で、JOINしたアビ情報のうち、sort_noが０の行だけを対象として検索する事にした。そうすればCOUNT(DISTINCT *)で事足りる。
カウントはDISTINCTで、実際の検索はGROUP BYで行うようにした。多分今度こそ大丈夫w
絞り込み条件によって、fatal errorが出るようになってしまった。要確認。
注釈がNULLの時に０番目の注釈を取りに行くが、そこのサブクエリが２行以上帰る場合があるというエラーがでていた。
条件を考えても２行以上になることはないので、データがどこか間違っている可能性が高い…がどこだかわからない。
とりあえず、DISTINCTで行をまとめる事で逃げるしかないのだけれど、
怪しいのは、水と光属性のサポアビの中なので、後でちゃんとじっくりとチェックしておく必要があるだろう。
とりあえず先に進める。
本番でもエラーになってしまった…。
原因は、同じab_id, ab_noに対し、複数のab_sort_no=0の行がある事。
group by ab_id, ab_no having count(ab_sort_no) >2
でチェックしたところ、全体で30件近くの不整合が見つかった。情けなす…。
とりあえず全て修正し、distinctをつけずともエラーが発生しない事を確認した。(前回出てた奴も正しく検索できるようになった)
データの整合性に関しては、一度ちゃんとチェックしないといかんのだろうなぁ…。
とりあえずこれで収束したろうか。
フリー検索は従来より時間がかかるので、検索中を表すアイコンを表示するようにしてみた。
jQueryのajax関数の成否判定が、実は古かった事も分かったので、あわせて修正。これで、検索中はくるくる回るようになった。
が、表示位置がどうもしっくりこない。スマホではどっか変な所に表示されているようだし…。その辺りはとりあえず後回し。
表示位置はpositionの指定で解決。
画像divにposition:absoluteを指定すれば、親コンポーネントの左上を起点に「絶対指定」となるつもりだったが、どうも「ブラウザ左上」が起点になってた。
結論から言うと、position指定したコンポーネントから親を遡って、一度もpositionが指定されていなければ、「何も指定してない(static)」のがデフォルトになる事から、positionもブラウザ左上のままだった…と理解した。
そこで、親コンポーネントに「position:relative」を指定し、子として指定する画像に改めて「position:absolute」を指定した。
意図通りの位置に表示させる事ができた。
ついでに、画像の大きさもminを使ってレスポンシブ対応した。
ただ、透過GIFがうまく透過されない…。
WordPressの古いバージョンだと上手く透過できないって事例はあったが…、もう直ってるって情報もあったので、使ってるテーマ(twenty-seventeen)の影響かも？
一度、media.phpに手を入れてみて試すのもありかもしれない。
ただ、その方法はサイト全体のGIF表示に適用されそうな気がする。やるならテンポラリだな…。
アニメGIFをアニメPNG(APNG)にしたら解決！
そうか、今時GIFじゃねーんだな…。
全部対応終わったら、ヘルプにフリーテキスト検索の事を書かないといけない。
…と同時に、ヘルプの切り替えについて以前断念した奴をもう一度ちゃんと見直してみよう。ちゃんと追っかければわかるはずだし。
ヘルプ(ページの切り替え)は、キャッシュやイベントの発火順が関係していたみたい。
まず、jQueryで全てのページを一旦非表示(display:none;)にした後、該当ページを表示(display:block;)にして表示させようとしていたが、関数内でblockに変わって表示された後、関数を抜けた所で一気にnoneになっているようだった。即時反映とかあるのかもしれなかったが、ここはeachで１つずつ判定しながら、表示と非表示を切り替える事にし、どうにかこうにか対応完了。
現状、全てのページ名(dt)が表示されているが、隠した方がカッコイイかな？
スマホ実機でヘルプの挙動がおかしかったように思ったんだけど、今試してみたら上手くできてた。JavaScriptがキャッシュされてたままだったか？
調べようと、実機でDevTools使う方法とか探しちゃったが…。
いや、できるんだね。ただケーブル(というかUSBハブ？)がどうにも調子悪いから、今度専用にちゃんとUSB接続できるようにしとこうかな。(今回は使わずに済んだけど)
さて、明日はヘルプの本文作ろうか。
日本語はエラーメッセージと共に、ヘルプ画面も完了。
statテーブルに検索した文字列を残したいとしていたが…。
それをやると、ちゃんとサニタイジングとかしなくちゃいけなくなるのよね…。大した処理してるわけではないから、プリペアードステートメントのテストも兼ねてやってみようかな。
全体的なレイアウトについて、少し手を入れてみた。
最初にレイアウトを作った時、flexを使っていい加減に作ったこともあるけれど、ちゃんとやればそれなりに表示させられた。
ただ、レイアウト見直すには時間もかかると思うので、作りこみ全部終わってからにしたい。
まずは、通常検索/フリー検索の切り替えをどうするか。
(ロジック的には、通常検索＋フリー検索も可能な気がしている)
次は英語画面への組み込み。
そしてヘルプの改修。
機能面ではこれくらいかな。
後「ガード」がまだ残ってるので、データを「ブロック」に直さないと。他にも旧データが残ってると思うので、考えないと。
通常検索＋フリー検索に関しては、技術的には全然可能だけど、それをやるメリットが見当たらない…。
絞込みの一種として考えるというのはあるんだけど、それをフリー検索で行うより、属性や種別などで絞り込む方がいいし速い。フリー検索はやっぱり重いし。
ORで考えると、効果または単語というのは、嬉しいかもしれないけど、結局効果が絞り切れないから属性とかで絞り込む必要がある。
それならば、「複数の効果」を選べる方がいいよねぇ…。
という事で、今回は「選択」と「フリー」は排他にすることにした。
フリーテキスト欄に１文字以上文字がある場合は、選択エリアを選べないようにする。クリアなどで０文字に戻ったら選択可能に戻る。
どっちにしても、フリーテキスト欄に文字がある間は通常の検索は行わない仕様になってるので、それを視覚的にも操作的にもわかるようにした。チェックボックスやラジオボタンで選択させるのもありだったが、操作の手数を考慮したら、「クリア」ボタンで消せばいいだけの方が楽かな…と。
ただ、入力した文字列を残したままにしたいケースがあるかもしれない。どっちがいいかねぇ…。ひとまず、は今の仕様でやってみる。使ってみて煩わしいようなら、チェックボックスなどを追加する方向で考えたい。
英語画面のレイアウトが上手くいかない。
CSSは日本語と同じはずなのに、どうしてだろう？
あんまり集中できてないから、明日にしようかな…。
半角で「100%」として検索すると、正しい検索結果にならない。全角で「１００％」はうまくいくのに。これはちゃんと確認が必要。
単純な話だった。
「％」はLIKE文でのワイルドカードでしたじゃんw
エスケープ(str_replace)で解決。
英語画面に着手。
・ヘルプの表示関連はOK
・ヘルプ本文は未
・フリーワードとエラーチェックは動作完
(ただし、今は日本語フィールド見てる)
・選択部のレイアウトが変。CSSは日本語と同じはずなのに…。
・くるくるが表示されない。
こんなところかな。明日頑張ろう。
英語画面完了。
動作も問題なし。ただ、日本語と英語で、おそらく「注釈」部分の記述の差で、同じ単語指定してもHit数が変わってしまうケースがある。(100%、70%をORで検索時など)
これはデータ直さないといけないし、まぁ仕方ないかな…。
使ってみて、英語の時は指定した単語が完全一致して欲しい気がする。日本語の場合は「文中に含む」が検索の通例だけど、英語の場合「単語」を指定したら、その「単語」で検索して欲しい気がする。(「up」で検索するなら「upper」とか「suplemental」とかはHitしてほしくない)
考慮が必要かなぁ…。明日ちゃんと考えてみよう。
英語画面のみ「Exactly Match」のチェックボックスを設け、それがチェックされた場合には、「LIKE ‘% up %’」と指定された単語を空白で挟むようにした。厳密な「完全一致」とは言わないが、目的には合致するのでいいかな～と。
見た目上は英語画面だけだけど、日本語画面にも埋め込んだので、処理自体は共通化されている。
さて、これでそろそろやりつくしたかな？
後、画面レイアウト(CSS関連)の全体的な見直しをしようかと思う。(スマホ画面でラジオボタンの間隔が狭いなど)
「Exactly Match」だと「完全一致」だが、実際は大文字小文字等の区別が無く、全然「完全」じゃない。
そこで、「Word Match」モードに名前を変える(単語単位での一致という意味)
別途、「Exactly Match」を設けて、大文字/小文字等を区別し、入力されたままの文字で検索をかける。日本語も同じなので日本語画面にも入れてみた。(動作確認未)
画面全体のレイアウトについて
・ラジオボタン(スマホ版)の見直し
・ヘルプ画面の見直し(開閉の範囲、閲覧中に閉じる場合など)
・スマホ版の「同一アビはまとめる」の文字長
・全体的に、スマホ版の文字の大きさ関係
・「検索」ボタンの位置(フリーワード入力時が気になる)
・フリーワードの履歴はやっぱり欲しいかなぁ…。
とりあえずこんな所か…。結構あるな…。
入力履歴を残そうと思うと、「autocomplete」をONにする必要がある。しかし、実際に履歴が残るのは、そのフィールドに「Enter」が反応した場合のみ。
通常、Enterでsubmit()が発火してしまうので、submitを何らかの方法でOFFにする(return falseなど)と、なんと履歴が残らない…。
これは、イベント発火の順番によるものだろうとは思うのだけど、バブリングを制御するなんてこたぁできないだろう。
もう少し調べてみようとは思うが、最悪はEnterキーで検索実行…までにとどめようかと思う。
(それだけでも、結構利便性は上がる)
履歴は今回はパス！
EnterキーでSubmitせずに検索が走るだけにとどめた。
ヘルプ画面の見直しは完了。細かな操作も作りこんだ。だいぶ使い勝手は上がったと思う。
検索ボタンの位置も変更した。フリーワードの直下に置いて、かつ幅を広げた。スマホでもPCでも使いやすくなったと思う。
「まとめる」の文は日英共に短くして改行されないようにした。
ラジオボタンも、margin: 0 5px 0 0;で後ろに若干の空白を入れて、スマホでも前後がくっつかないようにした。２行になっちゃったけど、元々２行になってたしいいかな。
プルダウンの幅も見直して、常時１行で並ぶようにした。
ただ、未選択状態で表示される文字列の調整は必要かもしれない。
(読めないものを入れておく意味が？)
調整した結果、スマホ版の文字は現状でも問題なさそうに思う。文字拡大とかされるとまた違うかもしれないが…。
とりあえず、見た目関連はこのくらいにしておこうかと思う。
プルダウンのデフォルト文は現状のままで行く。
(プルダウンリストを開けば全部読める)
CSSのcheckedの指定の仕方、セレクタ結合をきちんと理解できていなかったので、若干変な状態になっている。
input.class_nameA:checked ~ .class_nameB { /* */ } ;
として、inputタグにclass_nameAを、styleを変えたいタグにclass_nameBを指定し、それらが「連続で並んでいる場合」に適用されるのが自然な形に思えるので、全体的にそのように修正したいと思う。
また、現状では
という形で書くのではなく、
みたいに書く方が良さそう。
この場合、前述のCSSの指定がどうなるのか、確認が必要だと思う。
絞込み条件で、いずれかが選択されている場合、そうとわかるような表示をどこかにしたいと思ってる。
何かが選択されていたら、リセットボタンを活性化し、それ以外は日活性というのが、本来なら一番良いのだけども、それ以外の方法として、「絞込」ボタンの横あたりに、インジケーターを表示させる事を考えている。
おそらく、JavaScriptで書けば手っ取り早いとは思うのだが、この際CSSをちゃんと調べて、CSSでどこまで可能なのかを試してみたいと思ってる。
ただ…、なんとなくうまく行かなさそうな気がしてるｗ
もうちょっと頑張ろう。
CSSのみでやるには「:has」が有用なようだ！
…がブラウザがサポートしていないw
JavaScriptでは、サポートしているらしく、addClass()などを使えばひょっとしてできるかもしれないのだが確認の仕方含めて難しいっぽいので、現状は諦めようかな。
JavaScriptで実装する方向で検討しよう。
JavaScriptで実装した。
jQueryのchangeメソッドは、部品やformを監視できるとあったのだが、試してみると<div>にも普通に使えた。
絞込み画面は表示/非表示を切り替える為、divで囲んであるが、そのdivにchange()で関数を追加した。
そして、変更の度に$(‘#opt_div input:checkbox:checked’).length()のようにして、配下のチェックボックスのcheckedになってる数を数えて、インジケーターの透明度を０と１．０に切り替えるようにしたらうまくできた。
本来はdisplay:blockとnoneを切り替えてもいいかとも思うが、なんとなく透明度でやってみた。
リセットボタンが押された際にも、ちゃんと反映されるようにした。
ただ、何も選択されてない時に、リセットボタンの表示が変化したいのは何か気持ちが悪い…かな。
(そこだけ見直しておこうか)
とりあえず、大きな修正は終わったので、ここまでを一旦バックアップしておこう。
やり残してる事
・ラベルとインプットの入れ子関係(for句を使うかどうか)の見直し
・HTMLに直接書いてるCSSの外だし
・リセットボタンの活性化処理
・正式アイコンの作成
・英語のプルダウンの初期表示文字列
アビリティの情報を表示する際、現状はアビリティ名を選択するとアビリティ詳細画面へ遷移するようになっている。
しかし、いちいち画面遷移していては使いづらいと思われる。
そこで、アビ情報(アビ名、概要、注釈)については、一覧画面上で確認できるようにしたい。
アビ名の横に「ふきだし」マークを設けて、そこを選択したらアビリティ情報をポップアップするようにしてみた。
「ふきだし」は、CSSのみで実装。案外うまくできたw
アビリティ情報は、以前画面遷移のトリガー用に作ってあったダイアログを流用してみた。ただ、どうにもデザイン的にしっくりこない。(表示領域とかがうまくハマらない)
もう少し調整したいのと同時に、アビ情報画面と同じ色情報で表示させたいのだが、CSSを見直したいと思う。何とかもう少しスマートにレスポンシブ対応したい。
アビ名を選択した場合と、ポップアップ画面上で画面遷移を選択した場合は、従来のようにアビ情報画面へ遷移する。
ポップアップ画面が表示されると、フック関数内でreturn false;して処理は中断されるが、その際に画面遷移に必要な情報を全てセットした状態で中断させる。そうすることで、画面遷移のボタン(単にsubmit)が押されると、セットした情報を元に画面遷移するようにした。
ついでに、ポップアップ画面の外側をクリックするとポップアップも閉じるようにした。
ポップアップ画面上から、キャラ情報へ遷移できるボタンも追加した。これで当初のダイアログでの遷移案に回帰してしまったw
ただ、一覧画面を大きく変えず、どちらでもできるようになったと考えればまぁいいやw
一覧画面から、リンク(アンカータグ)を経由して、画面遷移などを行っているが、その際にデータ(アビリティID等)はdatasetを駆使してきた。
しかし、どうやらフック関数に対し、データオブジェクトを渡せるようだった。
$(‘#XXX’).on(‘click’, { data:param, data2:param2 }, ‘foo’ ) ;
みたいな感じ。渡せるのはObjectだが、入れ子も可能。
そこで、従来datasetで受け渡していた全てのデータを、これ経由に変更してみた。これでHTMLのソースが見られたとしても、一見しては受け渡してるデータは見えなくなる。どうせ表示用のデータだけだから良いのだけど、スッキリしてる方がいい。
詳細画面、アビ情報画面の中も現状はdatasetを使っているが、ここは全部手直ししておきたい。
一覧画面の修正は完了。
本当なら、アイコンにはリンクの下線は持たせたくないのだが、何故かうまく消えてくれない。WordPressのどこかで上書きされちゃってるかもしれない。
あわせて、マウスカーソルの形状を変更したい。
今回、アイコン上のカーソルは「選択」に変えたが、他のいろんな所のカーソルがマチマチになっていた。せっかくなのでちゃんと揃えたい。
そもそもの話として、「a」をアンカーとして使ってない(onclickを登録してる)のなら、「a」ではなく「span」でもいいのでは？
良かったw
という事で、キャラアイコン(img)とふきだし(span)はアンカーではなくspanに変えた所、下線は消せた。そもそもspanで囲む必要性も多分無い…が、どうしようかな。将来何かあった時のことも考えてこのままにしておこうかな。
同時にカーソルもpointerに変えたので、検索結果一覧上は完了。オプションやヘルプは未設定。
ヘルプ画面と各種オプションのカーソルも全て変更完了。
従来、一覧画面の上ではアビリティの概要などの情報は保持していなかった。そこで、アビリティ名が選択されたら、a-jaxで通信して概要などを持ってこよう…と思っていたのだが、今回は検索時に一緒に持ってきてしまう事にした。
所詮、検索件数の上限は５０件だし大した負荷にはならないだろうという判断。それに作りが圧倒的に簡単になる。
概要が長くなるとアンカータグが酷い事になるかとも思ったが、dataオブジェクト経由にしたのでソース自体を見ても気にならないw
概要と注釈を持つ事で、ポップアップ表示時に「該当する単語」の色を変えて表示するなども可能かもしれない。要検討。
一覧検索する際、概要はサマリーテーブル、注釈は詳細テーブルにそれぞれ持っていて、Hitする行によっては注釈がNULLのケースがあり得る。
基本的に注釈は表示用行番号が0の行にしかセットしていない。なので、複数の効果を持つアビリティの場合、該当する効果が行番号１以上になると、概要はあるが注釈が無いレコードができてしまう。
解決策としては、注釈を全レコードに持たせるというのもあったが、さすがにデータを大量に修正する事になるので他の手を考えた。
結果としては、注釈がNULLだった場合、サブクエリを用いて行番号０の注釈を持ってくる事にした。(０でもNULLの可能性はある)
最初にHitした行のアビIDと更新番号が一致する表示用行番号０を選択して、その値を使う。なぜかDISTINCT指定しないとSQLエラーになるがまぁいいか…。
これで、一覧取得時に必要なデータは全て取得してこれるようになった。
サブクエリも時間かかるかもしれないとは思うが、こっちもたかだか５０件だし多分大丈夫。使ってみた感じでは体感速度は大差ない。ひとまずこれで様子を見ようと思う。
データ不整合で、ab_sort_noが０の行が複数含まれてしまっていた。
データを見直した結果、distinctも不要になった。
理屈が通らないのにそのままにしてちゃアカンね。
ちゃんと理由があるのだから、もっとちゃんと考えて対応しなきゃいかんかった。
フリーテキストのHitした単語の色を変えるのをやろうかと思ったけれど、現状「テイスベル」で「ディスペル」がHitする以上無理だw
そういえば、英語で「Exactly Match」と指定した場合でも、「upper」と「uPPer」はHitしてしまうな…。全然「完全一致」じゃ無いwまいっかw
Exactly Matchを「単語の一致」として、それとは別に「曖昧一致」を設けるのであれば、「この単語、どこにHitしたのか？」ってのがわかる方が嬉しいかもしれない。
「ていすべる」で「ディスペル」の色が変わって表示されたら、そこがHitしたとわかるもんね。
前向きに検討！
具体的にやろうとすると、どうやる？
これでHitするのはMySQLの
COLLATE utf8_unicode_ci
で自動的にやって貰ってるだけなので、色を変えるとしたらこれを自力でやらないといけなくなる。
preg_replaceでできる範囲でやろうかとも思ったけど、うまくいかないので、今回は諦めよう。
スマホ画面とPC画面で、検索結果の２カラム目の幅がイマイチうまくない。
現状50vwとしている部分をmaxとかminをうまく使って調整したいところ。
後、アビ名が長くなると途中で改行されてしまい、「ふきだし」の位置もズレてしまう。大きなズレは無いが、リンクと重なってしまうので、どうしよう…。もう少し位置を下げればいいとは思うが、他に手は無いか考えてみる。
(今でも動作的に不便はあんまりないのでいいっちゃぁいいw)
CSSを調整。ついでに一覧結果の高さも調整。
幅はmaxとかを使おうとかも思ったけど、割合で十分とみた。
「ふきだし」の位置も、すこーし下げてリンクと重ならないようにした。
ダイアログの表示は概ね完了。
ただ、ダイアログ用にCSSを弄ったせいで、キャラ情報表示時のアビ説明文領域がおかしくなってしまった。
width: 20vw ;
を外したせいだと思うけど、外したのはダイアログ上の表示の関係でなので、うまく両立させられないかな…。今度こそ、max()やmin()の出番ではないだろうか？要確認。
後、概要(など)の文字数でウインドウサイズが変わってしまう。大きさは固定にした方がいいかもしれないな。(できるんだろうか？)
再使用間隔の表示が、サポアビや奥義にも表示されてしまうので、そこをオフれるようにしたい。
display:noneをセットすればいいかなぁ…。ただ、どうやって判定するかは良く考えたい。
ボタン配置や背景色、タイトルバーなんかもちゃんとしたいので、ここも調べる必要あり。閉じるボタン(「×」)の色もおかしいので、ここも何とかしたいんだけどな…。
(これ、確か前も悩んだ気がする)
残りはこれくらいかな。
一度注釈付きのアビを表示すると、次に注釈がセットされるまで、前回のものが残ってしまう。
削除するなりなんなりせねば。
修正完了。注釈が無かった場合に空文字をセットした。
説明文領域は、style.cssの該当クラスに
width: max( 30vw, 350px ) ;
を設定しなおす事で回避。(従来は20vwだった)
var(–contentWidth)という変数？があって、これが部品の幅を持ってこれるなら、その計算結果と30vwの大きい方(小さい方)ってやり方の方が良さそうなんだけど、サポートしてない？
少し調べてみようかな。
var(–XXX)は、単に変数を使ってるだけだった。
どこかで(:rootなどで)
–contentWidth: 800px ;
とか宣言しておくことで、
max( 30vw, –conentWidth ) ;
みたいに使えると理解した。
–contentWidth: fit-content ;
とか宣言すれば、後で使えるかな～とかも試してみたけど、うまく働いてる気がしない。とりあえず上の修正で今はやめておこう。
widthを適切(?)に設定した事で、ウインドウサイズもあわせて直った。まぁこれでいいだろう。
再使用間隔の判定はswitch~caseを使うのが本来だろうけども、凄くなんとなくで連想配列(該当するキーの値はtrue)で判定するようにしたw
スクリプトっぽいし(謎)。
再使用間隔がnull(再使用不可)の場合に対応。
詳細画面との不整合は完了。
ウインドウサイズも完了。
再使用間隔について完了。
ボタン配置と背景色(余白など)は完了。
タイトルバーとかは、これでいいか悪いか判断つかないw
別に困らないしとりあえずこれでいこうかな。
ダイアログ関連はこれで完了でいいと思う。
絞込み画面を閉じるボタン(領域)を、画面下部に追加したい。
今ずいぶん広くなっちゃってるから、選択した後に上にスクロールさせないと閉じることができないのは不便。
下部に(ヘルプと同じような)閉じる領域を追加しよう。
「＿＿＿＿＿▲＿＿＿＿＿」
みたいな表示を入れて、閉じるボタンと同じ動作させればいいはず。
「▲」は::afterでやればいけるんじゃないか？
::afterで問題なくできた。
クリック(on( ‘click’))で、開く用のcheckboxをcheckedに変えて、開く時の関数を呼び出しただけ。
問題なく動作できた。
::before、::afterの使い方に慣れてきたかな。
英語で「単語一致」の時、無条件に’% word %’としてしまうと、文章先頭の単語に一致しない…。
おそらく、末尾もダメだろう。
CONCATする際、前後に空白いれちゃおうか…。
CONCAT_WS( ‘ ‘, ‘ ‘, columna, columnb, ‘ ‘ )
で前後と中に空白入れて試したらうまくいった。
…けれど、あまりに安易だなw
本来ならどうすべきか、ちゃんと考えたいけれど、とりあえずはこれで行く。
やり残し。
・英語画面へのダイアログ(CSS)の反映
・OPTの閉じるボタン
・曖昧検索関連のヘルプ記載
・labelにfor句
・内部に持ってるCSSをstyle.cssへ
・正式アイコン
・フリーワードをダイアログ中で色変え
・リセットボタンの活性化処理
うわ、結構あるなw
英語画面のダイアログ終わり。
オプション領域の閉じるボタン(エリア)も終わり。
(あわせてエリアの表示を少し弄ってみた)
「曖昧」検索を日英に追加して、ヘルプにも記載完了。
リセットボタンの活性化処理も終わり。
(jQueryのnotがうまくはまった。フォーム全体の内、開閉チェックボックス以外のcheckedの数をカウントして制御)
フリーワードの色変えは見送り(というか断念)。
labelのfor句、CSSの外部化はとりあえず保留。今回は公開を優先。
正式アイコンは、この後やってみてできたら入れ替えてみよう。
よし、以上だな。
ログへの出力と、ログの閲覧画面どうしようかな…。
ログへ出力やってみた。
閲覧画面はまたいずれ…。
閲覧画面作ってみた。
でも、テーブルをスクロールさせようとすると、レイアウトがズレちゃう。色々面倒くさいし本筋の所ではないので妥協w
うう、文頭の単語や特殊文字で囲われた単語にHitしないなぁ。
もう遅い…、早急に直して修正ださんと…。