スキンのブロック化と、ロジックとデザインの分離†
- ページ: BugTrack
- 投稿者: tomix
- 優先順位: 低
- 状態: 提案
- カテゴリー: その他
- 投稿日: 2005-01-30 (日) 16:41:04
- バージョン:
メッセージ†
次期PukiWikiへの願望です。
1.44以降、スキン,CSSが少し複雑になってきて、PHPに詳しくない僕のようなものにはカスタマイズしにくくなってきています。*1 tDiaryラッパーで簡単なカスタマイズ方法が提供されたとはいえ、表示要素のカスタマイズはやはりスキンまで手を入れたくなります。
Smartyを入れるまではいかなくっても、自作スキンページで紹介されているPukiwiki and Smartyで
も述べられているように、ローカルのホームページ作成ソフトである程度カスタマイズできるように、スキンを以下のような方法で整理するしていくというのは今後どうでしょう?
- レイアウトを構成するブロックに整理する
- 各ブロックを構成する要素を呼び出す部分はSmartyのように{pw-hoge}とか、MTやColdFusionのように<pw-hoge />のような方法で記述し、ローカルで編集可能にする*2
- レイアウトに関係ないロジックの要素、条件分岐が必須となるもの(DTDの分岐とか)は極力個別のオブジェクトにしてスキンの外にだす。
- 1つのスキン+条件分岐をやめ、表示パターンによって複数のスキンを作る方向にする(閲覧スキン、編集スキン、検索スキンなど)ページの状態によってどのスキンを使うかはスキンの上流で振り分けるようにする(スキン内で判断しない)
- 複数スキンにしても共通レイアウト要素はインクルードで共有することで見た目の統一を図ることができるようにしておく <pw-Includ:hoge/hoge>のようなもの?
- CSSファイルはPHP化しない(印刷用、表示用は別に個別に用意する)
- UA固有のバグに対する対応をスキン側でムリにしない。*3
PHPってHTMLとプログラムをごちゃ混ぜにできる気軽さが売りなようなところもあったと思うので、プログラムができる人にはあっちこっちにファイルが散在しちゃって面倒なだけかなぁ...そこがPHPの長所でもあり、短所でもあるとおもうんだけど、ぼちぼちスキンは、ロジックとデザインをわけてほしいなぁと...*4
- 確かに、スキンやCSSにロジックの要素が含まれていると、改造しにくいです。理解するだけで一苦労だったりして。 -- ありぃ
- これまでのあらすじ: 今(1.4.4)まで、デフォルトのスキンは(言語ごとに)二種類に、デフォルトのCSS(わずか1色用)は(言語とメディアごとに)四種類存在している世界でした。どの部分をカスタマイズするにも手間が多く、自作スキンといっても日本語用のファイルしか添付できない世界でした。デフォルトの状態で多色化を実現するなど夢のまた夢でした。これに対する対策が現状の措置(それぞれ一本のPHPに集約)です。 -- henoheno
- どうもPukiWikiの場合、スキンファイルというものは良くも悪くも「最後にロードされるPHPファイル」の域を脱していない様です。様々な不具合をケアしようとすると、どうしてもスキンファイルの中にロジックが入ってしまいます。そして、そのスキンしか要求しないようなロジックがあると、そのような要素はPukiWiki本体に組み込むべきでないのでスキンの中に残ってしまうのですね。 - henoheno -
- この「最後の抽象化レイヤー」*5からデザインを分離させるには、いっそのこと新たに「Smarty化するためのスキン」とか「テーブルタグを排した新世代向けスキン」を作ってみた方が良いのではないかと思うのですが、いかがでしょう。 -- henoheno
- henohenoさんが進まれている方向は新しいスキンやCSSを読んでてわかってきていました。確かにそのスキン特有のロジックはその扱いにこまりますね。まずはテーブルレイアウトから脱皮して*6、ロジックを含むモジュール化された各要素を、目的にあったスキンファイルにレイアウトする方法がとれれば、カスタマイズ*7は楽になるなぁと思っています。ちなみに例えば5~10ぐらいのモジュールをスキンにインクルードするというアプローチをとるのはパフォーマンス的にかなり問題があるものなのでしょうか? -- tomix
- やってみなければわかりませんし、作り方がうまければ何でもそこそこうまくいくと思います。いたずらにファイルを撒き散らしたりするとメンテナンス性は著しく落ちるでしょうし、必要最小限のモジュールだけロードするような作りであればコンパイル時間が短くなるかもしれませんね。 -- henoheno