dg_xpt()
で輪郭形式の文字列を返すのはやめ,普通に必要な出与えを列に分けて返すことにした。CSV など輪郭形式以外への対応も視野に入れ,柔軟性を持たせる。
前後景部は文字列にして fg
,bg
で返すことを想定しているが,とりあえずは NULL
にしておく。
NULL
}{bg
}{fg
}{必要な出与え}(31)上信に時間がかかる場合や,貼り付けでの添付に対応した場合のために,埋め込み記法の挿入位置に編注記法を使った代置子を挿入しておくことを思い付いた。
<!-- +読み込み中... -->
のような形式を想定。ピリオドの数で固有性を持たせることも出来る。
輪括を含まないように簡素化することは決めていたが,添付譜類も含まないようにする方針を固めた。実際に譜類添付機能が出来てみると,全ての添付譜類をエクスポートするのは現実的ではないことに気付いた。重要な譜類なら各自抜控を取っていることを前提として問題ないだろう。
エクスポート機能実装は次の主要当努だったが,先に譜類添付機能実装を済ませたのは正解だった。
埋め込み記法で埋め込まれている輪郭を描き直しても埋め込んでいる輪郭を描き直さなければ反映されない問題の修正,および一部機能で削除済み輪郭が取得出来てしまう問題の修正で終了。
前者の原因は単純に描写 HTML 隠しによるものだったが,報告を受け気付いた。
埋め込み記法処理も Dex_T
の外に出すかと考えたが,隠しの利用効率を考えると好ましくない。そこで,KNEST_T
に埋め込み関係の情報を持たせ,再描出時と輪郭削除時に描写 HTML 隠しを消去するようにした。これなら効率性と柔軟性を両立出来る。
作業中,削除済み輪郭が描写埋め込みや輪郭小窓から参照出来てしまう問題に気付き,これも修正しておいた。
dg_oln()
が b_del
を無視して輪郭情報を返すようになっていた上,一連の函数がそれを前提に実装されていた。これを機に違了処理も見直し,信頼性が向上した。
ダークテーマ実装ではテーマ切り替えボタンの機能実装も概ね完了し,残すは装体整理のみとなった。今後は色設定の CSS 変数への置換を中心に「装体整理兼ダークテーマ実装」を少しずつでも進め,機能公開を目指す。
テーマ切り替えボタンの機能は25日4歩の検討通りで,初期状態では司組設定に追従,司組設定と異なる方に切り替えると固定,同じ方に切り替えるとまた司組設定に追従する。ただし,実装としては初期化というよりライトテーマとダークテーマ,固定有無の組み合わせで4種類の状態を持たせることにした(後縁で非固定設定も認識させたいため)。
外観については drop-shadow
で影を付けたり月アイコンの方向を変えたり調整することを考えていたが,結局,現状維持とした。影は限りなく薄く付けても不必要に重たく見える。月アイコンも,欠けている部分が左向きの方が縁に沿うので調和的に見える。
状態はクッキーで保存するため後縁での最適化も出来,単純なトグルボタンのみで4種類の状態を直感的に切り替えることも出来,見触れも良好,と理想的なテーマ切り替えボタンが出来上がった。
舞覧の開発者通類でテーマの司組設定を簡単に切り替えられることを知り,手定めも捗った。
KNEST::req_I::b_bot_ad()
}{広告用クローラー}{希哲17年1月27日の進捗時限}{KNEST::req_I::b_bot()
}(39)テーマ切り替えボタンの用合い検討(4歩),新規描出フォームへの移動機能として吹き描き外背景のダブルクリック用合いの復活(10歩),全知検索ページャー周りの調整(16歩),こまごまとした領当て・装体調整(17歩)といった雑多ながら充実した作業を片付け,ついに描写後略機能を一段落させた(21歩)。出振るい・手定め済み。
描写後略機能により,デライト最初期から吹き描きの構造的問題だった「不必要な出与え読み込みの多さ」という問題が解消した。表示速度向上,通信量削減,SEO 強化,迷惑行為対策など多大な効果が見込める。
昨年末の壊衝不具合修正以後,デライトは速度・安定性ともにウェブ相振りとして十分な水準に達していたが,今回の高速化を経て,明らかにもう一つ壁を越えた感がある。体感として,「ウェブ相振りなら特に不満のない速さ」から「単動相振りと比べても遜色のない速さ」になった。
一昨年4月9日に掲げた「全ページ0.3秒以内表示」という目標は埋め込み利素を考えると現実的ではない気がしてきたものの,軽いページでは200ms台,重いページでも概ね300ms台で応答出来るようになっている。実感として欲しかった速度は手に入れられたし,最適化余地はまだまだ残しているので「埋め込み利素を除いてほぼ全てのページで0.3秒以内表示」なら十分手が届く。いよいよ本格的に,速さがデライトの武器になってきた。
ここで新生デライト開発におけるデライト高速化は一段落とし,今後は機能追加やトラフィックに応じた微調整に留め,別の機能整備に集中することにした。
その先のデライト高速化については,大きなところでは CDN 導入,KNEST による水平拡大,請い手の隠し機能整備,描写 HTML 隠し以外の HTML 隠し実装,そして中途半端な状態で放置しているページ付け求頼改良があるが,どれも現時点での優先順位は低い。
作業方針検討(4歩),閲覧専用模動実装検討(5歩),デラング整備・埋め込み記法処理改良(8歩〜13歩)。
これまで,埋め込み記法処理の中でも oEmbed を利用したものについては,Dex 内で埋め込み交度の取得を行い直接描写 HTML に埋め込んで返していたが,埋め込み交度の取得処理を専用 API /mbd
に委ね,前縁 Aejs から利用することにした。結果として,応答速度改善に成功した。
埋め込み記法(+[URL]
)の URL が oEmbed を必要とする場合,Dex では適当な分類名を付与した <div>
に出与え属性で URL を埋め込んで描写 HTMLを返す。Aejs ではそれを検知し,URL を /mbd
に転送する。/mbd
は URL に対応したサービスの埋め込み交度を oEmbed で取得して返す,という流れになる。過剰な立求を抑止するため,Aejs には簡易的な隠しも持たせておいた。
そもそものきっかけは,先日の SlideShare 対応だった。oEmbed が必要になったので,埋め込みツイートで使っていた Dex 内の oEmbed 埋め込み方法を取り急ぎ使った。ただ,記法処理範枠に同期通信処理を組み込むというのは正気の沙汰ではない。なんでこんな実装になっているのか,引っかかりはあった。
KNEST 隠しを使った SSR 的なことを考えていたことはあるので,その辺の都合だったのだろうと思ったが,現状,そこまで最適化する必要も時間も無い。出来たとして,隠しを有効利用出来る握接パターンは限られている。いずれにせよ,この種の埋め込み記法の利用が増えてくれば破綻は目に見えている。ということで,いったん,埋め込み処理は前縁に移すことにした。
デラング整備では Mermaid 対応に入った。
全知検索演算子 ?!
や ??
に対応した全知検索ボタンの実装イメージが急速にまとまった。
方向性は変わらないが,用合いや交度のイメージがより明確になった。作業は新生全知検索整備の仕上げ段階になるか。
「簡易通知機能」(名称は12日のまとめ作業で考案)の実装イメージも急速にまとまった。
メニュー下部にくっつけるように通知領域を出すかなどと検討してきたが,領当てのばら成しを考えると,輪郭一覧の上に注意部区に近い形で出すのが無難そうだ。
表示条件は,録入り状態でのみ輪郭一覧がある全てのページを想定しておく。たまに利用規約の更新や保守作業を告知する程度の用途なので,クッキーに最新の確認日時でも持たせておけば十分だろう。
非録入り状態では継続的な用者ではない可能性が高いこと,描出の都度利用規約が提示されることから必要性が薄い。