BugTrack/790
の編集
Top
/
BugTrack
/
790
[
トップ
] [
編集
|
差分
|
履歴
|
添付
|
リロード
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
|
ログイン
]
RIGHT:&size(12){Category:[[Design>:Design]], [[CSS]]}; *スキンのブロック化と、ロジックとデザインの分離 [#ddd5ba8b] -ページ: BugTrack -投稿者: [[tomix]] -優先順位: 低 -状態: 提案 -カテゴリー: その他 -投稿日: 2005-01-30 (日) 16:41:04 -バージョン: ** 関連 [#ja23ad31] - [[BugTrack/714]] CSSの一部をPukiWiki上から変更 - [[BugTrack/789]] CSSの多色化 **メッセージ [#m3896b29] 次期PukiWikiへの願望です。 1.44以降、スキン,CSSが少し複雑になってきて、PHPに詳しくない僕のようなものにはカスタマイズしにくくなってきています。((特に条件分岐が多いところ)) tDiaryラッパーで簡単なカスタマイズ方法が提供されたとはいえ、表示要素のカスタマイズはやはりスキンまで手を入れたくなります。 Smartyを入れるまではいかなくっても、自作スキンページで紹介されている[[Pukiwiki and Smarty>http://lab.ajibit.com/?Pukiwiki%20and%20Smarty]]で も述べられているように、ローカルのホームページ作成ソフトである程度カスタマイズできるように、スキンを以下のような方法で整理するしていくというのは今後どうでしょう？ +レイアウトを構成するブロックに整理する +各ブロックを構成する要素を呼び出す部分はSmartyのように{pw-hoge}とか、MTやColdFusionのように<pw-hoge />のような方法で記述し、ローカルで編集可能にする((Smartyのほうが要素がローカルでも見えるから使い勝手がいいかも？Dreamweaverもたしかこの形式で動的部分の置換要素を記述していたと思う...)) +レイアウトに関係ないロジックの要素、条件分岐が必須となるもの（DTDの分岐とか）は極力個別のオブジェクトにしてスキンの外にだす。 +１つのスキン＋条件分岐をやめ、表示パターンによって複数のスキンを作る方向にする（閲覧スキン、編集スキン、検索スキンなど）ページの状態によってどのスキンを使うかはスキンの上流で振り分けるようにする（スキン内で判断しない） +複数スキンにしても共通レイアウト要素はインクルードで共有することで見た目の統一を図ることができるようにしておく <pw-Includ:hoge/hoge>のようなもの？ +CSSファイルはPHP化しない（印刷用、表示用は別に個別に用意する） +UA固有のバグに対する対応をスキン側でムリにしない。((標準CSS ＋UA振り分けライブラリ→バグ箇所のみ上書き用CSS)) PHPってHTMLとプログラムをごちゃ混ぜにできる気軽さが売りなようなところもあったと思うので、プログラムができる人にはあっちこっちにファイルが散在しちゃって面倒なだけかなぁ...そこがPHPの長所でもあり、短所でもあるとおもうんだけど、ぼちぼちスキンは、ロジックとデザインをわけてほしいなぁと...((がんばってPHPとも格闘してんだけど...)) ---- -確かに、スキンやCSSにロジックの要素が含まれていると、改造しにくいです。理解するだけで一苦労だったりして。 -- [[ありぃ>official:ありぃ]] &new{2005-01-30 (日) 17:43:17}; -''これまでのあらすじ：'' 今(1.4.4)まで、デフォルトのスキンは(言語ごとに)二種類に、デフォルトのCSS(わずか1色用)は(言語とメディアごとに)四種類存在している世界でした。どの部分をカスタマイズするにも手間が多く、自作スキンといっても日本語用のファイルしか添付できない世界でした。デフォルトの状態で多色化を実現するなど夢のまた夢でした。これに対する対策が現状の措置(それぞれ一本のPHPに集約)です。 -- [[henoheno]] &new{2005-01-31 (月) 21:17:45}; -どうもPukiWikiの場合、スキンファイルというものは良くも悪くも「最後にロードされるPHPファイル」の域を脱していない様です。様々な不具合をケアしようとすると、どうしてもスキンファイルの中にロジックが入ってしまいます。そして、そのスキンしか要求しないようなロジックがあると、そのような要素はPukiWiki本体に組み込むべきでないのでスキンの中に残ってしまうのですね。 - [[henoheno]] - &new{2005-01-31 (月) 21:17:53}; -この「最後の抽象化レイヤー」((抽象化レイヤーとしての最たるものは tDiaryスキンですね。tDiaryのテーマを利用可能にするこそがあのスキンの仕事なのですから))からデザインを分離させるには、いっそのこと新たに「Smarty化するためのスキン」とか「テーブルタグを排した新世代向けスキン」を作ってみた方が良いのではないかと思うのですが、いかがでしょう。 -- [[henoheno]] &new{2005-01-31 (月) 21:18:04}; -henohenoさんが進まれている方向は新しいスキンやCSSを読んでてわかってきていました。確かにそのスキン特有のロジックはその扱いにこまりますね。まずはテーブルレイアウトから脱皮して((すでにありぃさんが自作スキンで実現されていますね。僕もやってみたいと思っています。次期バージョンはテーブルとはさようならかなぁ))、ロジックを含むモジュール化された各要素を、目的にあったスキンファイルにレイアウトする方法がとれれば、カスタマイズ((改造するというより、バリエーションを増やすという方向がベスト))は楽になるなぁと思っています。ちなみに例えば５～１０ぐらいのモジュールをスキンにインクルードするというアプローチをとるのはパフォーマンス的にかなり問題があるものなのでしょうか？ -- [[tomix]] &new{2005-02-01 (火) 00:16:44}; -- やってみなければわかりませんし、作り方がうまければ何でもそこそこうまくいくと思います。いたずらにファイルを撒き散らしたりするとメンテナンス性は著しく落ちるでしょうし、必要最小限のモジュールだけロードするような作りであればコンパイル時間が短くなるかもしれませんね。 -- [[henoheno]] &new{2005-02-07 (月) 21:36:25}; #comment
タイムスタンプを変更しない
RIGHT:&size(12){Category:[[Design>:Design]], [[CSS]]}; *スキンのブロック化と、ロジックとデザインの分離 [#ddd5ba8b] -ページ: BugTrack -投稿者: [[tomix]] -優先順位: 低 -状態: 提案 -カテゴリー: その他 -投稿日: 2005-01-30 (日) 16:41:04 -バージョン: ** 関連 [#ja23ad31] - [[BugTrack/714]] CSSの一部をPukiWiki上から変更 - [[BugTrack/789]] CSSの多色化 **メッセージ [#m3896b29] 次期PukiWikiへの願望です。 1.44以降、スキン,CSSが少し複雑になってきて、PHPに詳しくない僕のようなものにはカスタマイズしにくくなってきています。((特に条件分岐が多いところ)) tDiaryラッパーで簡単なカスタマイズ方法が提供されたとはいえ、表示要素のカスタマイズはやはりスキンまで手を入れたくなります。 Smartyを入れるまではいかなくっても、自作スキンページで紹介されている[[Pukiwiki and Smarty>http://lab.ajibit.com/?Pukiwiki%20and%20Smarty]]で も述べられているように、ローカルのホームページ作成ソフトである程度カスタマイズできるように、スキンを以下のような方法で整理するしていくというのは今後どうでしょう？ +レイアウトを構成するブロックに整理する +各ブロックを構成する要素を呼び出す部分はSmartyのように{pw-hoge}とか、MTやColdFusionのように<pw-hoge />のような方法で記述し、ローカルで編集可能にする((Smartyのほうが要素がローカルでも見えるから使い勝手がいいかも？Dreamweaverもたしかこの形式で動的部分の置換要素を記述していたと思う...)) +レイアウトに関係ないロジックの要素、条件分岐が必須となるもの（DTDの分岐とか）は極力個別のオブジェクトにしてスキンの外にだす。 +１つのスキン＋条件分岐をやめ、表示パターンによって複数のスキンを作る方向にする（閲覧スキン、編集スキン、検索スキンなど）ページの状態によってどのスキンを使うかはスキンの上流で振り分けるようにする（スキン内で判断しない） +複数スキンにしても共通レイアウト要素はインクルードで共有することで見た目の統一を図ることができるようにしておく <pw-Includ:hoge/hoge>のようなもの？ +CSSファイルはPHP化しない（印刷用、表示用は別に個別に用意する） +UA固有のバグに対する対応をスキン側でムリにしない。((標準CSS ＋UA振り分けライブラリ→バグ箇所のみ上書き用CSS)) PHPってHTMLとプログラムをごちゃ混ぜにできる気軽さが売りなようなところもあったと思うので、プログラムができる人にはあっちこっちにファイルが散在しちゃって面倒なだけかなぁ...そこがPHPの長所でもあり、短所でもあるとおもうんだけど、ぼちぼちスキンは、ロジックとデザインをわけてほしいなぁと...((がんばってPHPとも格闘してんだけど...)) ---- -確かに、スキンやCSSにロジックの要素が含まれていると、改造しにくいです。理解するだけで一苦労だったりして。 -- [[ありぃ>official:ありぃ]] &new{2005-01-30 (日) 17:43:17}; -''これまでのあらすじ：'' 今(1.4.4)まで、デフォルトのスキンは(言語ごとに)二種類に、デフォルトのCSS(わずか1色用)は(言語とメディアごとに)四種類存在している世界でした。どの部分をカスタマイズするにも手間が多く、自作スキンといっても日本語用のファイルしか添付できない世界でした。デフォルトの状態で多色化を実現するなど夢のまた夢でした。これに対する対策が現状の措置(それぞれ一本のPHPに集約)です。 -- [[henoheno]] &new{2005-01-31 (月) 21:17:45}; -どうもPukiWikiの場合、スキンファイルというものは良くも悪くも「最後にロードされるPHPファイル」の域を脱していない様です。様々な不具合をケアしようとすると、どうしてもスキンファイルの中にロジックが入ってしまいます。そして、そのスキンしか要求しないようなロジックがあると、そのような要素はPukiWiki本体に組み込むべきでないのでスキンの中に残ってしまうのですね。 - [[henoheno]] - &new{2005-01-31 (月) 21:17:53}; -この「最後の抽象化レイヤー」((抽象化レイヤーとしての最たるものは tDiaryスキンですね。tDiaryのテーマを利用可能にするこそがあのスキンの仕事なのですから))からデザインを分離させるには、いっそのこと新たに「Smarty化するためのスキン」とか「テーブルタグを排した新世代向けスキン」を作ってみた方が良いのではないかと思うのですが、いかがでしょう。 -- [[henoheno]] &new{2005-01-31 (月) 21:18:04}; -henohenoさんが進まれている方向は新しいスキンやCSSを読んでてわかってきていました。確かにそのスキン特有のロジックはその扱いにこまりますね。まずはテーブルレイアウトから脱皮して((すでにありぃさんが自作スキンで実現されていますね。僕もやってみたいと思っています。次期バージョンはテーブルとはさようならかなぁ))、ロジックを含むモジュール化された各要素を、目的にあったスキンファイルにレイアウトする方法がとれれば、カスタマイズ((改造するというより、バリエーションを増やすという方向がベスト))は楽になるなぁと思っています。ちなみに例えば５～１０ぐらいのモジュールをスキンにインクルードするというアプローチをとるのはパフォーマンス的にかなり問題があるものなのでしょうか？ -- [[tomix]] &new{2005-02-01 (火) 00:16:44}; -- やってみなければわかりませんし、作り方がうまければ何でもそこそこうまくいくと思います。いたずらにファイルを撒き散らしたりするとメンテナンス性は著しく落ちるでしょうし、必要最小限のモジュールだけロードするような作りであればコンパイル時間が短くなるかもしれませんね。 -- [[henoheno]] &new{2005-02-07 (月) 21:36:25}; #comment
テキスト整形のルールを表示する
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
