テンプレートに XSLT スタイルシートを使う利点
俺はもうテンプレートが XSLT じゃない日記システムないし CMS ツールは使えない人間になってしまったのだけど、なんで XSLT を使うかを考えてみた。
- アプリケーション間で使いまわししやすい。(仕様化されているので)
- ホスト言語をあまり制限しない。(仕様化され、ライブラリが存在するので)
- not well-formed にはまずならない。(XML プロセサが処理をするので)
- インデントがまとも。(XML プロセサが処理をするので)
- (タグなどに関しては) sanitize を言わなくてすむ。 (XML プロセサが処理をするので)
- やろうと思えば XPath 関数を増やせるので、拡張性が高い。
- パズルちっくで (書いていて) 楽しい。(裏を返せば読みにくいのだけど)
XPath の話も混ざってますけど、どうせ一緒に使うからいいよね。
メリットを書くならデメリットも書くべきだけど、そんなに思いつかない。
- とにかく元が XML じゃないと話にならない。
- ちょっと難しいことやると難読になる。
- XPath 1.0 が貧弱。
- 最初は template がどんな意味を持つのか理解できない。XPath が地味に難しい。
- 難読まで行かなくとも、読むのが面倒くさい。(上から順番に実行されるわけではないから)
思いつかないとかいいつつ結構あるね。
一番重要なのは、アプリケーション間で使いまわしやすいことだと思う。共通のテンプレートを作っておけば、それを include したりして、それぞれ別のシステムから利用できる。このサイトはヘッダとかフッタとかナヴィゲーションとかは XSLT の1ファイルにまとめて書いてある。だから CSS のスタイルを作っても適用するのは全く面倒くさくない。ようは別々になってるとめんどいのよ。面倒くささ解消のために標準化標準化
関連エントリー
- XSLT で行をマークあっぴ 汎用っぽいテンプレ作っていたら、XSLT だけで一行ごとに l 要素とかソレっぽいのでマークアップできることに気付いた……っていうかアレだ。...
- サイト全体を XML + XSLT ? サイト全体を XML データをもとにして XSL 変換したほうが楽っぽいなぁ。辞書とか、ヘッダ・フッタとかの共通部分を完全に一箇所にまとめら...
- Ruby/XSLT て パラメータ渡せないくさいんだけど、もし本当にそうならあんまりこのまま使えないなぁ。XSLT ファイルを一回パースして xsl:param に...
- XSLT と XPath の理解 とりあえずカレントノードとコンテキストノード。 カレントノード = current() で、コンテキストノード = self::node()...
- xml とかデータ型とか tDiary のデータを移行するのはやめることにしよう。 XML がデータだと脳内 DTD でも XSLT でてきとーに変換できるのになぁ…...