ブログ

昨日は大丈夫だと思っていたのに、三人目のソーンの入力をしていたら、やっぱり色々気になる所がでてきて修正してしまい、今日も一人分しか完了しなかった。これ、１９０人分終わるのいつだ？ｗ

と言いながらも、後から修正するよりははやめに直した方がいいに決まってるし、お尻が決まっているわけでもないから、ここは割り切って良い物ができそうだと前向きに考えておこう。実際、データ入力前に比べると色々と表示内容や制御方法などは改善されているのでいいだろう。

先日学んだ、dataset配列もPHP側で生成したものをJavaScriptで受け取るという応用ができたし(タグでdata-XXXと指定すると、dataset[“XXX”]でアクセスできる)、日々成長は実感できている。無理やりやっていた処理(idに連結した文字列を設定し、JSで分離)も、個別にアクセスできるようになったので随分すっきりした。

さて、明日は一つ懸念のある、サラーサの入力に取り掛かる。サラーサはモードチェンジがあるので、それがどのように表示されるのか、又何か特別な考慮が必要なのかがこれで明かになるだろう。これがうまくできれば、サーヴァンツやナルメア、ユイシスも問題なく実装できるはずなので、ここさえ乗り切れば後は何とかなるだろう。

なんか、結構手を入れないといけないような悪寒はするwまぁ頑張ろうｗ

プルダウンメニューの絞込みで、<option>タグに何か情報を持たせ、それを使って実施しようと考えて、最初の頃に作った絞込み用の処理を見ていると、「data-val」という項目を設定している部分があった。その時は新規にこのようなプロパティが追加になっているという認識だったのだが、どうやら違っていたようだ。

<option value="1000" data-level="1">大項目１</option>
<option value="1100" data-level="2">中項目１</option>
<option value="1101" data-level="0">小項目１</option>
<option value="1102" data-level="0">小項目２</option>
<option value="1200" data-level="2">中項目２</option>
<option value="1201" data-level="0">小項目３</option>

こんな風にHTMLを書いておくと、JavaScriptでこの「data-level」の値が取得できるようだ。

var pulldown1 = document.getElementById( "pulldown1" ) ;
var selected_index = pulldown1.selectedIndex ;
var selected_level = pulldown1.options[selected_index].dataset["level"] ;

こんな感じで、選択した項目のレベルを取得する事ができ、判定に使えるという事らしい。成る程！set/getAttributeみたいのもそう言えばあったような気もするけど、この「data-XXX」という手法を用いれば、HTML5準拠で、jQueryでも扱いやすくなるようだし、これを活用してみよう。

そういえば、他の部分でもタグにデータを持たせたいと思ってた処理がいくつかあって、無理やりnameとかidを使って対応した部分があったはず。また後日この部分もdataset配列で実装し直した方がいいだろうな。nameやidは本来の用途で使いたい。

同一アビリティでレベルによって更新されるものがあるが、検索結果にはHitするもの全てを表示するようにしている。しかしデータが増えてくると、バリエーションが多い(といっても、最大で３だが)アビリティは少々うざくなる。行数制限なども必要になってくるので、同じアビリティに関しては１行で表示するオプションが必要なのは承知していた。(そのつもりでチェックボックスは既に用意してあった)

SQLで重複行をまとめるのであれば「DISTINCT」しかないだろう。

SELECT COUNT(DISTINCT detail.ab_id) FROM ab_detail_tbl detail

こうかけば、重複しているIDはまとめられて１行としてカウントされる。では、実際のデータのSELECTはどうするか？

SELECT DISTINCT detail.ab_id, detail.ab_name, detail.ab_type
  FROM ab_detail_tbl detail

こんな感じに通常だとなるのだが、同じidなら当然名前も同じなのでいいのだけれど、タイプによってレコードを分けている関係上これは意図した通りにまとまらない。つまり、ab_typeが同一ab_idで複数存在した場合にまとめる事ができない。

PostgreSQLの場合にはこれは次のように書けるらしい。

SELECT DISTINCT ON(detail.ab_id), detail.ab_name, detail.ab_type
  FROM ab_detail_tbl detail

しかしながら、残念な事のMySQLではこれは採用されていないようだ。ではどうするか。サブクエリを発行してそこから重複ID分を除くという手段もあるようだったが、GROUP BYが使えるような感じだった。次のような感じ。

SELECT detail.ab_id, detail.ab_name, detail.ab_type
  FROM ab_detail_tbl detail GROUP BY detail.ab_id

試してみると、意図通りにCOUNTと同じくIDだけに着目した重複のまとめが実現できた。DISTINCTじゃなく、GROUP BYだと実際SELECTされてからキャッシュ内でまとめ処理が走るような気がするので、性能的な懸念はあるのだが、それはサブクエリとそんなに差は無いのではないだろうか？そして、そもそも大量データになる場合はカウントで除外するようになっているので、致命的な性能劣化はおきないのでは？と考えている(というか期待している)。

テストはこれで実施してみよう。

昨日のエントリの通り、一部画面などがおかしい部分が明らかになったので、その修正を実施した。一つはテーブルに入力したデータ自体が間違っていたもので、必要な情報を加える事で正しく表示されるようになった。

もう一つはバグではないが、バリエーション(Lvで更新のある)アビリティの表示に伴い、キャラクター画面上に、どのレベルで変更があるのかを示唆する表示を加えた。

変更のあるレベルがデータとして存在する場合、そのレベルを表示するようにした。囲み型のショートコードで次のように記述してみた。

[has_data data1]<br />(Lv[show_data data1][has_data data2]/Lv[show_data data2][/has_data]で更新)[/has_data]

何となく、これはダメな気はしていた(同じショートコード名の入れ子はNGだったような)のだが、表示させてみると…。

<br />(LvXX/LvXXで更新)[/has_data]

となってしまった。やはり同名のショートコードの入れ子はうまくいかないようだ。仕方が無いので、同じ機能ではあるけれど、別名のショートコードを作成し登録するようにした。ひょっとして、add_shortcodeの引数を変えて、同じ関数を登録してもOKかもしれないね…。試してみよう。

ともあれ、別名のショートコードであれば問題なく動作するので、データ追加によるキャラクター表示画面の修正はこれで良さそうだ。ただ、キャラクター画面からアビリティ画面への遷移はより欲しくなった印象。データの入力が終わったら取り掛かろう。

データの入力が着々（？）と進んでいるが、ようやく２キャラ目のデータ入力が完了した。(キャラ概要、キャラ詳細が完了し、アビ概要が十天衆分完了している)

アビ詳細を入力しなければ、そもそも検索でヒットしないので、ウーノ分のアビ詳細データを一通り入力してみたが、軽く検索してみたらやっぱりところどころおかしな部分があるｗ

考慮が足りてない分がいくつかあるので、その辺りの修正もしなくてはならないのだが、データの入力値がおかしい可能性もあるので、そこらへんもちゃんと確認しないといけない。一旦バグ修正をしてから、データ入力は再開した方がいいかもしれない。

それにしても、中々思うように進まないなぁ…。公開もうちょっと先延ばしにせざるを得ない状況になってきた。今月中ではなく、来月にしようかな…。真剣に考えよう。

といっても、キャラクター情報は概要と詳細の２つのテーブルがあるうちの、概要テーブルの方が終わっただけ。しかも、ＳＳＲキャラのみ。召喚石やＳＲやＲなどはまた別途考慮するので、取りあえずＳＳＲのキャラクターのみ入力が終わればそれでよし。

まず、キャラクターの情報を入力する事で、すべてのキャラのＩＤが決定する事になる。アビリティのＩＤはこのキャラクターＩＤに紐づいているので、アビリティＩＤも自ずと決まっていくというわけだ。

アビリティは相当な量になるため、これの入力完了を待っていては恐らく時間がかかりすぎる。テスト用の公開もする必要があるのに、それを待ってはいられない。そこで、特徴のあるアビリティや奥義を持つキャラクターを優先的にデータ入力して行く事で、様々なテストが可能になるはず。

チョイスとしては、最終解放が存在しているキャラ、十天衆、二人一組(メイドやラン＆ヴェみたいな奴)、モードで入れ替わる奴(ナルメアやユイシスなど)、効果の種類が多大な奴(ソーンやアニラみたいな奴)、フィールド系を持つ奴(ザルハメリナ、イシュミール)、奥義ダメ無い系(コルワ、コッコロ)あたりかな？

後はできる限り英語名は入れていこうと思って手をつけ始めたら、これは面倒だし後回しだｗ５０音順とアルファベット順で並びが全然違うし、英語表記で全然日本語名が想像つかない奴とかもいたりして、これは結構難儀しそう。

ともかくキャラ情報はできたから、次は上記チョイスに従ってキャラをピックアップして、キャラ詳細テーブルの入力に取り掛かろう。

アビリティの再使用間隔の表示を、どのページにどういう風に表示させようか悩んでいる。今日までで、結果表示画面は「アビリティ」と「キャラクター」という２種類にわけて表示するようにした。キャラクター画面には各アビリティの名称や効果(説明)などが表示されているのだが、その細かいデータをそこに全部盛り込むのは微妙に思っている。

では、アビリティ画面に持たせるのか？というとどこまで持たせるのが良いのか悩む。

この機能を使う人は、まずアビリティの種別からアビリティの一覧を見て、そこから自分の目的にあったアビリティなのかどうかを知りたいはずだ。そこで、アビリティを選択しアビリティの情報を表示させたなら、アビリティ名や説明だけでなく、どのような効果か、何ターン持続するか、再使用間隔はどれくらいなのか、レベルで変化するのか、などが知りたいはずだ。

そうか…。一覧でアビリティ名とそのレベルがわかるとしても、アビリティ画面で再度レベルによるバリエーションがあるのであれば、それを表示できるようにすれば利便性が高いかもしれない。つまり、変化するレベルの同一アビリティへの遷移ができればそれでいいのでは無いだろうか。

それなら、一覧ではレベルによるバリエーションを表示させる意味がどれくらいあるのだろう？以前考えたように、同一キャラでも最終解放まで終わっている場合、複数のアビリティが表示されてしまう。そうするとあっと言う間に表示上限に達してしまうのではないだろうか。だったら、検索画面では同一アビは１行に表示させ、アビリティ画面で別レベルの表示が選択できれば良いのではないだろうか。

振り出しに戻ってしまった感じがするｗ

テーブルのTDタグのクラスに、データのアビリティ種別によって、異なるクラスを指定したいと思い、以下のようなショートコードを書こうと試みた。

<td [class_short_code]>データ</td>

しかし、どうやってもうまく動かない。どうやらタグの中のショートコードはセキュリティ上の問題を引き起こす可能性があるのか、動作しないようになっているらしい。となると、結構面倒臭いことになりそう。例えば…

[class_selector 1]<td class="$$$">データ</td>[/class_selector]

みたいに囲み型ショートコードでタグ全体を囲み、PHP内のcontentで、$$$を文字列置換して出力する(do_shortcodeの再帰呼び出しでは無く)ようにすれば可能だとは思うのだが…。本当にそれでいいの？

もっと他にいい方法は無いだろうか。ぱっと思いつくのは、JSでダイナミックにクラスを指定する事なのだが、スマートでは無いよなぁ。もう少し思案してみよう。まぁ今の内にこの手の制限に気付けてよかった。

キャラクター情報を表示する画面を作成している。データをDBから取ってくる際、随時か一度に取得するか悩んでいたが、JOINを使いまくって(つーても１０個くらい？)試してみたが、問題なさそうだったので、これでやってみようかと思う。

アビリティと違い、キャラクターは一意に決まる(DISTINCTしているが、必要ないかな？)ので、JOINが一杯でるのと、SELECTを十数回繰り返すのでは、多分JOINの方がリソースを食わないと…思いたい。(これは後でチェックが必要だろう)

必要なデータの取得方法が定まったので、暫定的な画面デザインを実施している。やはりテーブル表示が一番収まりがいいのだが、これは色々試すしかない。あんまり凝らずに、デザインの決定は公開後にやりたいとは思っているが、必要最低限はやっておきたい。

特に、アビの種別で色を変えるなどは、プログラムが必要になる部分でもあるため(種別によって使用するCSSのクラス名を変更するなど)、一応抑えておきたい部分になる。クラス指定でうまくいってくれるといいのだが、例のCSSの優先度がどうなるかによって変える必要もあるだろう。

また、表示する項目についてももう少し検討は必要だろう。アビリティのIDを取得しておいてあるのだが、キャラクター表示画面からアビリティ画面への遷移を見越しての措置になる。必要あるか無いかはそれも又検討が必要かもしれない。

とにかく、アビ画面とキャラ画面の根本は完成したと言っていいだろうから、細かい部分んが終わったらいよいよデータの入力に入らないといけない。CSVの入力はOpen.orgのCalcでやっているが、やる前にバージョンアップしておいた方が良さそうだな。先日は落ちまくったし…。

画面がある程度できたら、色々と思い悩み始めてしまった。

本当に使えるものにしたいので、少々手戻りがあってもここはちゃんとしたい。

元々、アビリティ検索というのが主目的だけど、変に欲張って機能を増やすのは実力に見合わない、高望みになって完了しないという最悪な事も考えられる。そこで、アビリティ検索というので、利用者がどういう事を求めているかを考えたい。

とはいえ、まず自分のやりたい事を形にするのが先決。その為にアビリティを検索した後、簡易表示と詳細表示に分けるようにしていたが、簡易表示画面に自分が見たいと思う情報を集約させる事にした。本当に細かいデータ(効果量など)を表示させるとしたら、従来は詳細画面へ…と思ったのだが、実際に表示するとしたら(データが用意できるかどうか次第だが)どこに表示される方が嬉しいか？となると、やはり簡易画面側だろうと思う。

複数結果を選択して表示するならなおさら。比較したいのは効果量とかであり、名前比較してもしょうがないでしょうw詳細画面をキャラ情報(簡易情報)とするのなら、渡すべきはアビリティ情報ではなく、キャラIDのみで良いはず。ただ、どのアビを選択したのかってのがわかった方がいいのだろうか？

いずれにせよ、ちょっと手戻りも考え直しも入っているけど、ここをキッチリやって次にいきたいと思う。でも中々すすまんのｗ