昨年10月1日の開発では ?!
の導入は保留することにしたが,当初予定通り,?!
,!?
,??
の3種類を揃えることにした。
少なくとも前縁では全知検索ボタンの切り替えに必要なことに気付いた。11日の開発でこのあたりの実装イメージがまとまったことで気付きやすくなっていた。後縁での実装がどこまで必要かは実装しながら考える。
src
属性}{<script>
}{希哲16年12月19日の副日記}{付かない}(192)長いこと課題だった自我ページと風船輪郭について良い閃きがあり,急速に実装方針がまとまった。
現状,自我ページは URL のみ正規化している(/KNo.XXXX
)が内容は単なる自我知番での検索結果であり,プロフィールページとしては貧弱過ぎる。自我輪郭などの案はあったが,既存機能や領当てとの整合性をとるのが難しく,自我ページとしてはなかなかイメージがまとまらなかった。かなり難航しそうだったため,新生デライトの要件にも入れなかった。
最近の大輪郭整備で必要性を強く感じるようになっていたこともあり,もう少し現実的に,低コストで実現出来る案でまとめてみることにした。
まず,他自我内検索の用合いを既存の自自我内検索と整合させるため,以下のように,自我アイコンを並べるか重ねるかして,& ボタンで段階的な切り替えが出来るようにする。さらに,自我アイコンの下に「○○さん K#XXXX の描き出しです。」と表示する。
これで,全知検索の機能性はそのままに,プロフィールページに最低限必要なアイコンと名前の表示が出来る。自我アイコンの複数表示自体はかなり以前から他自我内検索用合いの案としてあったが,これに名前を添えてプロフィールページの見出しを兼ねさせるというアイデアが新しかった。
大した作業ではなく,新生デライトの完成の遅れも今更なので,これは新生デライトの要件に追加することにした。
2月23日頃から検索結果の改良について本格的に考え始めていたが,「検索属性」を導入し,検索結果の多段化を進めていくことにした。
現状,例えば括弧類を自動付加した検索は出来るが,その逆は出来ない。括弧付きで描出したい場合,括弧無しで検索して既存輪郭が無いことを確認した後,括弧を付けて再検索するということが多く,とりあえずこの手間を無くしたかった。全知検索演算子の制御に任意の括弧類を使えると好都合ということもあった。
文字数の昇順で揃えてそれなりの結果になっているのでこれを降順にすればいいかと思ったが,上手く行かない場面が多々あるので一時凌ぎの域を出ない。
将来的な拡張性も考えると検索結果の多段化が好ましい。風船輪郭や輪括内検索にも応用出来る。希哲14年7月30日8歩から輪括内検索は輪括内のみにすると使いにくいという理由で中途半端な状態になっていたが,優先表示で解決出来ることに気付いた。
整数値に揃えを兼ねた役割を与え,これを「検索属性」として利用出来るようにする。
ここまでは良いが,効率的な実装が難しい。単純に全ての検索パターンを UNION
で結合すればひどいことになるのは目に見えている。外充て函数で余計な検索を省くようにする,挿入・更新時に確定出来る情報はフラグ化しておくといったことに加えて,後縁での出力は最低限にして前縁で追加取得するといった工夫が必要になるかもしれない。
いずれにせよ後縁の対応は進めて問題ないだろう。設計方針さえ固まれば最適化はどうとでもなる。
silver
}{dimgray
}{black
}(65)前次部区装体では高さが固定されているため,ルビが含まれると下にはみだしていたが,昨日の装体調整後のパンくず記法でも似た問題があることに気付いた(区切り記号が上にずれる)。
前次部区に関しては Dex でルビ記法の有無を判定して調整するかと考えていたが,ここで,両方とも position: absolute
と bottom
で揃えればいいことに気付き,早速修正した。なんとなく気になって始めたパンくず部区装体調整に救われた。
ついでに,パンくず部区の中間区切り記号の色を dimgray
から black
に戻した(実装初期にも同じことをしていた:1月15日1歩)。表示環境によっては末尾の silver
と見分けにくい。線の太さなどを変えてみてもやはりしっくり来ない。