[PHP-users 2463] Re: ロジックとデザインの分離 (was: PHPと JSP の比較 )

松島 知弘 php-users@php.gr.jp
Thu, 04 Oct 2001 01:55:14 +0900


松島です。

> カスタムタグは別に「ロジックとデザインの分離」を唱えている
> わけではないです。

失礼しました。m(__)m

> っていうか、XSLとXSLTってどっちがなんだったか、いまだに使いわけれないので
> すが。

XSL  = Extensible Stylesheet Language
XSLT = XSL Transformations

前者は、ファイルの形式、または、UA側で行うXSL変換処理で、
後者は、XSL変換処理系、または、サーバサイドで処理されるXSL、
と覚えているのですが、もしかしたら間違っているかも…。

規格としては、きちんと区別されています。

> また、JavaのカスタムタグはXMLであり、本質的にはXSL(T)とかわらないと思いま
> す。実際に Jakarta-taglibsにはXSLというカテゴリーもあります。

XSLは、スタイルを整える役目のCSSと同類のものです。
なので、情報そのもの(XML)がなければ、修飾する対象がなくて
何も処理できません。XSLに「スタイル」以外の出力情報を
記述することは望ましくないと思います。(飽くまで 'Stylesheet')

なので、

<sample>
  <work>1</work>
</sample>

に対して、

<xsl:element name="p">
  <xsl:text>今日は</xsl:text>
  <xsl:choose>
    <xsl:if test="/sample/work = '1'">
      <xsl:text>仕事</xsl:text>
    </xsl:if>
    <xsl:otherwise>
      <xsl:text>休み</xsl:text>
    </xsl:otherwise>
  </xsl:choose>
  <xsl:text>だよ。</xsl:text>
</xsl:element>

の様にすると、スタイルシートの役目を超えてしまいます。
#これはそもそも、元のXMLも良くない。


> XML+XSL(T)の場合、いったんXMLデータを吐き出してXSLTで処理ということになる
> と思います。
> この場合、ネームスペースを始め、すべてが処理側とXSL(T)で独立しますよね?
> つまり、XMLデータという壁をへだてて、ロジックとデザインが隔離している状態
> だと思います。
> XML+XSL(T)のメリットは、非営利団体による標準化ということで、処理系非依存
> で共通化ができるということだと思います。
> XMLデータさえ吐き出してしまえば、JavaからでもPHPからでもCからでも共通の
> XSL(T)が使えると言う。

仰る通りです。


> JavaのカスタムタグはXML

厳密には、属性値に < > 等を含んではいけなかったような…。
まあ、PHPの <?= 〜 ?> や <?php 〜 ?> も、同様に
SGML/XML的には怪しげな記述なると思いますが(苦笑)。


> ホームページの場合、ロジックとデザインが密接にかかわるので、このように適
> 当に共有化ができたほうがいいと思うのですが。

?? ここでの「ロジック」とは、何を指していますでしょうか。
#デザイン側に渡すパラメータ? 演算処理アルゴリズム?

デザイン側で必要な情報(パラメータ)が全て取得可能な状態にある時、
それを超えて何の共有化が求められるのでしょうか。

パラメータ生成処理のロジックがブラックボックス化されている事が
デザイン側にとってのメリットに繋がると思っているのですが…。


#……とか何とか言いつつ、PHP+Sablotronは他の手法と比べると重いです。
#(どうも、プロセス生成されているような感じが…)
#XSLは略記法(?)を使っても、冗長な記述にならざるを得ない事がよくあります。
#Sablotron+expatが日本語やXSLT1.0に良く対応しだしたのは最近だったりします。
#その場限りのシステムでなら、選択するメリットはないかもしれません。
#
#でも、期待してる一人としては、どうにかしてエールを送りたいもので(^^;)。

──────────────────────────────
松島 知弘 matsushima@popup.org
          http://www.popup.org/ai/