脳log[20171115]

2017年11月15日 (水) 表示は HTML+CSSが一番よく知っていて使いやすい。A4に印刷できるし、印刷しなければリンクをクリックもできる。TABLEタグのグループ(table/thead/tfoot/tbody)がパジネイション(※カタカナではわからん。ヘッダ・フッタがページ分割に対応してるってこと)にも対応していて使いやすい。■悩むのがデータソース。永続データではなく表示のための中間データ。XMLをソースにするなら XSLTが使えるが、XMLはファイルに保存するには冗長だし、XSLTはちょっと遅い。IE(※互換モードでも可能だが10まで)+TDCなら TSVファイルをソースにできるが、古いバージョンの IEにロックインされてしまう。Webブラウザがインターネットへの窓口だからか HTMLはローカルのリソースからきっちり切り離されていてデータをつっこみにくい。それだけのためにサーバーは立てない。SCRIPTタグで読み込める JSONは XMLと同様に冗長。その冗長さが無用の可変性を持ち込むことに耐えられない。SQLの INSERT文はテーブル名とオプションの列名を記したあとは、値の組をいくつも羅列できて冗長さがない。というわけでよそから引っ張ってきた生データを最初は XMLファイルに保存していたが今は INSERT文として SQLファイルに保存している。XML+XSLが担っていたデータソース＋表示のための加工を SQLでやってる。■で、本当に悩んでるのが SQLiteから HTML+CSSへの橋渡し。sqlite3.exeがいろいろな出力モードを持っていて、HTMLの表にしたり、CSVにしたり、ちょっと工夫して JSONにしたりはできるんだけど、凝った表示をしたくなれば HTMLは HTMLファイルに書きたいわけで、sqlite3.exeが受け取る、SQLがメインのバッチファイルに HTML片を埋め込むのがつらくなってきた。なんなら HTMLを通して表示したいものを指定するパラメータを渡したりもしたいわけで、HTMLからどうやって可変性のある SQLをつついてその出力を埋め込むのか、その方法を考えてる。XSLTだとブラウザ(※Firefoxと IE)がローカルのデータソースへのアクセスとパラメータの受け渡し手段(XSLTProcessor/ActiveXObject("MSXML2.FreeThreadedDOMDocument.6.0")/XMLHttpRequest)を JavaScriptに対して提供していた。でも今は XMLより SQLをソースに使いたい気分。JSON+Template Literalsが落し所かなあと決まりかけてるんだけど(20171114)、JSONへの不満はもう書いたし、HTMLを JavaScriptの文字列として扱うことにも不満がある。こういう不満ですよ>「非表示の div要素の内容として JSON形式で全ページの HTMLが入っている。(20170906)」 なんでもできるよりそれしかできないの方がよっぽど価値がある。E4X(※今はもう亡い)をテンプレートにできなかったのかな。■なんだかんだ HTMLは孤立していて使えないし、IEはそれを補完して使えるやつだったし(TDCもそうだし src属性を持つ xmlタグもそう)、Firefoxも使える。Google Chromeはローカルリソースがまったく読み込めなくて使い道がない。Headless Chromeは Webブラウジングの、内部からではなく外部からの自動化に役立つかとちょっと調べてみた。アクセスに URLではなくクリックを要求してくる無駄に作り込まれたサイトに対処するために。内部からっていうのは、最初に(主にテスト目的の)アドオンを内通者としてインストールするとか、ユーザーが実行をトリガーするかしないといけないことを指す。ブラウザが認証情報を持ってるのがネックなんだろうけど、プライベートブラウジングモードでもダメなのか。■■■@2017-11-20「Shadow DOM (www.tohoho-web.com)」 template要素と slot要素。データアイランド(ただし可視)に Shadow DOMを関連づけてその配下にテンプレートのコピーを appendすると slot要素と slot属性が結びついているように見える。まず Firefoxが対応していないし、スクリプトでの逐次操作が必要そうだし、すでに完成していて新しいプログラミングパラダイムを見せてくれる XSLTの方がよっぽど使えるという印象。MDNのサンプルではユーザー定義要素とそのコンストラクタで forループを解消してるけど、そこまで要求するならサーバーサイドで動かすことしか考えてないのかな。Shadow DOMにおける slot要素は別々のものを必要に迫られたからなのだろうけどアドホックに雑ぜ雑ぜ(「混ぜ混ぜ」とは変換できなかった)してみただけに見えて、頭の中でモデルをイメージできない。それが自身の知識の不足ゆえであれば問題ないが、高次の構造の欠如によるのであれば使えない技術ってことになる。アドホックというのは演繹が働かず発展性がないということとほとんど同じ意味。■MS用語なのだろうか「XML データアイランド (msdn.microsoft.com)」 必要に応えて問題に対処する手段を提供していたマイクロソフトと、選択肢を奪った不可避の Windows Updateで問題を生み出し足を引っ張る現在のマイクロソフト(20170422, 20171117)。■■■@2017-12-26「ブラウザのしくみ: データ構造とアルゴリズムと雰囲気で理解する DOM と Shadow DOM — hayato.io」 slot要素は出てこない。ツリーのツリーをひとつのツリーに均す(flatten)過程に現れるのだと思うがそこは「魔法」の一言で片付けられた。「ツリーのツリー」は普通の木構造だろうか。ツリーを構成するノード(サブツリーのルート)の背後にまた別のツリー(Shadow Tree)があるのをなんと表現するか。■多重化されたツリーの図が Shadow DOM の本質なのだろうか。だとしたらデータバインディングに使うのは効率が悪い。データ(Shadow Tree)にも表示用テンプレート(Light Tree Node)にも定型が与えられない(=柔軟性がありすぎる)のだから。■「Shadow DOM (w3c.github.io)」 あ、反対だ。表示用テンプレート(Shadow Tree)とデータ(Light Tree Node)の組み合わせが正しい。Shadow Treeに多様性が不要なときに template要素をクローンして使えばいいのか。しかし HTML要素とその slot属性で与えられるデータが不定形だし視覚要素が全く無駄だし、そこにデータを置きたくないし。Shadow DOM ってビジュアルをアタッチする手段なのか？ 俺はデータをアタッチしたい。■「コンテンツはドキュメントに、見た目は Shadow DOM にあります。(www.html5rocks.com)」 HTMLを XMLだと思えばいいだけなのかな、かな？ それでは「すでに完成していて新しいプログラミングパラダイムを見せてくれる XSLTの方がよっぽど使える」という感想が覆らないなあ、自分の用途では。