Category xslt.

parameters= に渡す値はすべて自分でクオートしとこう。

libxslt はもともとパラメータの値に XPath そのまんま書けるんだけど、なぜか ruby-xslt の parameters= ではクオートして必ず文字列で渡す。しかしながら、なんかこのクオートの実装が狂ってて、自分でクオート付け足してる癖に Invalid expression とか言い出してくれちゃう。やれやれだぜ!

正確に言うとクオートを付与する段階で、与えた文字列を中途半端に破壊的に変更するらしく、クオーテーションがかたっぽだけ付く。セッションとかで保存させながらのコードでもうハマったハマった。dup してどうにかしたけど、自分でクオートして明示的に文字列にしたほうがよさげ。

ソースは読んでないので間違っているかも。あくまで挙動からの推測

  1. トップ
  2. xslt
  3. ruby-xslt の parameters=
  1. トップ
  2. ruby
  3. ruby-xslt の parameters=

俺はもうテンプレートが XSLT じゃない日記システムないし CMS ツールは使えない人間になってしまったのだけど、なんで XSLT を使うかを考えてみた。

  1. アプリケーション間で使いまわししやすい。(仕様化されているので)
  2. ホスト言語をあまり制限しない。(仕様化され、ライブラリが存在するので)
  3. not well-formed にはまずならない。(XML プロセサが処理をするので)
  4. インデントがまとも。(XML プロセサが処理をするので)
  5. (タグなどに関しては) sanitize を言わなくてすむ。 (XML プロセサが処理をするので)
  6. やろうと思えば XPath 関数を増やせるので、拡張性が高い。
  7. パズルちっくで (書いていて) 楽しい。(裏を返せば読みにくいのだけど)

XPath の話も混ざってますけど、どうせ一緒に使うからいいよね。

メリットを書くならデメリットも書くべきだけど、そんなに思いつかない。

  1. とにかく元が XML じゃないと話にならない。
  2. ちょっと難しいことやると難読になる。
  3. XPath 1.0 が貧弱。
  4. 最初は template がどんな意味を持つのか理解できない。XPath が地味に難しい。
  5. 難読まで行かなくとも、読むのが面倒くさい。(上から順番に実行されるわけではないから)

思いつかないとかいいつつ結構あるね。

一番重要なのは、アプリケーション間で使いまわしやすいことだと思う。共通のテンプレートを作っておけば、それを include したりして、それぞれ別のシステムから利用できる。このサイトはヘッダとかフッタとかナヴィゲーションとかは XSLT の1ファイルにまとめて書いてある。だから CSS のスタイルを作っても適用するのは全く面倒くさくない。ようは別々になってるとめんどいのよ。面倒くささ解消のために標準化標準化

  1. トップ
  2. xslt
  3. テンプレートに XSLT スタイルシートを使う利点
  1. トップ
  2. web
  3. テンプレートに XSLT スタイルシートを使う利点
  1. トップ
  2. cms
  3. テンプレートに XSLT スタイルシートを使う利点
  1. トップ
  2. blog
  3. テンプレートに XSLT スタイルシートを使う利点

  • child 子
  • parent (..) 親
  • attribute (@) 属性
  • descendant-or-self (//)
  • self (.)
  • descendant 子孫
  • ancestor 祖先
  • following-sibling 後兄弟
  • preceding-sibling 前兄弟
  • following 後
  • preceding 前
  • namespace
  • ancestor-or-self
  • comment()
  • text()
  • processing-instruction([target])
  • node()
.
self::node()
..
parent::node()
//
descendant-or-self::node()
@
attribute::

@ 以外は軸とノードテストを合わせた省略形

http://lowreal.net/logs/2006/01/03/1#content

  1. トップ
  2. xslt
  3. XPath1.0 いろいろ一覧