対応形式の大幅拡張に成功(16歩)。しばらくは画像だけでもいいかと思っていたが,整理が思いのほか捗った。
{開発}{開発記録}{譜類添付機能調整}{希哲17年3月26日の副日記}{希哲17年3月26日}{大幅拡張}{希哲17年3月の開発}{隠し機能}{
/mbd
}{対応形式}(18){希哲17年3月26日の開発 K#F85E/E74C-106A}
宇田川浩行{進捗記録}{進捗}{希哲17年3月26日の開発}{希哲17年3月26日の進捗}{希哲17年3月26日}{希哲17年3月26日の進捗時限}{隠し機能}{
/mbd
}{KNEST::cch_
}{KNEST 隠し}(16){希哲17年3月26日17歩 K#F85E/E74C-91D6}
宇田川浩行{開発}{開発記録}{一段落}{サービス}{希哲17年1月24日の副日記}{正常な}{壊衝不具合}{作業過程}{長大な描写}{絡み合う}(49)
{希哲17年1月24日の開発 K#F85E/E74C-D97B}
宇田川浩行{開発}{開発記録}{線}{サービス}{デライト}{デライトはoEmbedに対応している?}{描写下見機能}{希哲17年1月16日の副日記}{この手の}{埋め込み献典}(243)
{希哲17年1月16日の開発 K#F85E/E74C-6ADB}
宇田川浩行作業方針検討(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 的なことを考えていたことはあるので,その辺の都合だったのだろうと思ったが,現状,そこまで最適化する必要も時間も無い。出来たとして,隠しを有効利用出来る握接パターンは限られている。いずれにせよ,この種の埋め込み記法の利用が増えてくれば破綻は目に見えている。ということで,いったん,埋め込み処理は前縁に移すことにした。
読み込み中...
{進捗記録}{進捗}{希哲17年1月16日の開発}{希哲17年1月16日の進捗}{希哲17年1月17日}{希哲17年1月16日}{応答速度改善}{専用 API}{
/mbd
}{埋め込み記法処理改良}(25)