実験用次世代テーマを公募
minahito
XCube_PHP4 sand box で使うデータの公募始めました:
http://sourceforge.net/forum/forum.php?thread_id=1960794&forum_id=537172
以下愛用の翻訳ソフトによる翻訳
-----
プロジェクトは XOOPS2 仕様に制限されない次世代の方法を検討するためにテーマファイルを
必要としています。修正 BSD ライセンスとしてそれを提供して戴けないでしょうか？
要求仕様:
* ２もしくは３カラムのテーマ
* valied html + css
* 考えられうるスタイルの定義
テーマはセクション風、リンク集風（古いか）、ダウンロード風、ブログ風の各モジュールの試
作に使用されます。スタイル定義時は、これらのモジュールを基準に考えてください。そして、
どうやって未知のモジュールのためにスタイルを定義していくかを考えましょう。
「手続き」トラッカーからアプライしてください。
（話し合いとかはこのＭＬでＯＫです）
-----
ここまでは邦訳ですが、以下メモです。
○主に一枚を想定
一枚のインデックスファイルに書けるだけ書くフォーマットがメインになると思います。というの
も、 XOOPS Cube はレンダーシーケンスによる合成を前提としているため、 left.html right.html
に分割して theme.html 側で自主的に合成するような「インクルード」は想定仕様に含まれていま
せん。
（そういったケースは各レンダーシステムでの機能になります）
○マニフェストからプレースホルダを読み取る予定
XOOPS2 は５つのカラムで固定されていましたが、 XOOPS Cube ではマニフェストにプレース
ホルダの情報を書き、 BASE がそれを読み取って、管理画面から各タスクをレンダーシーケンス ID
に割り当て出来るようにする予定です。マニフェストにレンダーシーケンス ID を書くか、あくま
で識別子を書いて、 BASE 側でシーケンス ID を割り当てるかは実験しながら決めて行きたいと
思います。
○Rapid Weaver のテーマはビルトインモジュールぶんのスタイルしかない
XHTML+CSSテーマで見た目をガラッと変えてくる RapidWeaver は本体が持っているモジュール
が出力するテンプレートは決まっていて、テーマは主にそのスタイルを定義することで見た目を
変えます。そのため、本体のバージョンが上がると大体テーマも修正を迫られます。
アドオンは、「定義されているはずの CSS」を継承した CSS を吐いたりして画面を作っていく
みたいです。
○XHTML+CSS はもうないらしい
なんか HTML5 とかいうのに移っていくらしいですね……
詳しい人解説してください。 (-_-;;
jidaikobo
On Thu, 6 Mar 2008 08:21:57 -0800 (PST), minahito wrote:
> XCube_PHP4 sand box で使うデータの公募始めました:
http://sourceforge.net/forum/forum.php?thread_id=1960794&forum_id=537172
XCube_PHP4 sand box ってのがなんなのか、ピンときていません。
あたりまっちゅやあ、あたりまえの現象ポイですが、いまのところ、
検索しても minahito さんのドキュメントにしか遭遇できません ^^;
あと、この「次世代テーマ」ということでもとめられているのは、デザイン──
つまり見栄えのバリエーションでしょうか？ それとも構造のバリエーションでしょうか？
デザインのバリエーションだとすると、来月以降かなーという感じですが、
とりあえず触って何か、動きを見られるんだったら、合間々々に触れるかなとか思ったり。
自分の力量以上の世界っぽいことは何となく感じるんですが、
追っ付きたいとは思っているので、お手間をおかけして本当に申し訳ないんですが、
ちょっとハシゴを掛けてもらえるとうれしいです。
--
以下署名。
柴田宣史 - SHIBATA Nobufumi -
minahito
jidaikoboさんレスありがとうございます。(^^)
> http://sourceforge.net/forum/forum.php?thread_id=1960794&forum_id=537172
> 「テーマ」と書いてあれば、興味はあるんですが、まず、
> XCube_PHP4 sand box ってのがなんなのか、ピンときていません。
> あたりまっちゅやあ、あたりまえの現象ポイですが、いまのところ、
> 検索しても minahito さんのドキュメントにしか遭遇できません ^^;
ならなかった（滝涙
次期版候補のブランチのことです。
ちょっと古いですが、ダウンロードはこちらから可能です。
http://sourceforge.net/project/showfiles.php?group_id=159211&package_id=178668&release_id=560179
> あと、この「次世代テーマ」ということでもとめられているのは、デザイン──
> つまり見栄えのバリエーションでしょうか？ それとも構造のバリエーションでしょうか？
> デザインのバリエーションだとすると、来月以降かなーという感じですが、
> とりあえず触って何か、動きを見られるんだったら、合間々々に触れるかなとか思ったり。
XOOPS2 の場合は XOOPS2 テーマという叩き台があったのですが、今回はゼロからの出発になります。
アーカイブのサンプルはフリーのテンプレートを拾ってきて
技術者向けにタスクシステムとレンダーシーケンスを解説するサンプルになっているのですが、
XOOPS2 のようにブロックやコンテンツを実際に配置するのは少し厳しいテンプレートばかりなので、
そういった CMS での機能立証ができるような検証用のテーマの一連のセットが欲しいなと思って
公募を出しました。
タブメニューがあるテーマはどうする？
パンくずリストがあるテーマはどうする？
モジュールのテンプレートはテーマスタイルごとに分けて収録できるようにする？
等など、 XOOPS Cube がレンダリング周りを汎用化したことによる実用性の面はこれから
検証ということになってきます。
その後、収録したテーマやレンダーシステム、サンプル BASE などを見て、新たなテーマの体系
が作成されていくようになればと思いますが、まず当面は検証にとどまると思います。
XOOPS2ではブロックのアサインが５つのプレースホルダ、コンテンツのアサインが一箇所で固定
でしたが、今後はここは動的になります。
そういったことの検証と、
あとは、のちのちテーマやテーマのスタイルが検証しやすいように、 xoops.css 的なものの作成
ですね...
デザインがまずいにせよ table がよくないにせよ、
プログラマがモジュールにテンプレートを添付してまず配る！
という Do の面で XOOPS のテーマ体系はきちんと役割を果たしましたし、
それの新版を作るのは結構骨が折れると思います。
（といっても換装ができなかった XOOPS とは全然違うし、
作っていただいたものも最終的にはサンプルとして収録するだけになると思います
なので気楽にやってくださいませ）
JIDAIKOBO SHIBATA Nobufumi
On Mon, 10 Mar 2008 20:57:08 -0700 (PDT), minahito wrote:
> ちょっと古いですが、ダウンロードはこちらから可能です。
http://sourceforge.net/project/showfiles.php?group_id=159211&package_id=178668&release_id=560179
Core_XCube_20071208.zip なるものを落としてみました。
でも、恥ずかしながら、なにをしていいのか、全然わかりませんでした T_T
core と samples とある。ドキュメント（XOOPSCube1208_ja.pdf）をみるに
XOOPS Cube の実証実験だとある。
ということは、XOOPS Cube がいるのだろうな、と、Package_Legacy_2_1_3
をダウンロード。
core フォルダの中身は、たぶん /html/core/ に差し替えるといいのかなと上書き。
samples はよくわからないけど、index.php はきっと/html/index.php の上書きだろう。
/samples/simple01/config/ は、よくわからないけど、site_default.ini.php が
はいってるから、settings かな。そのほか classes.php とか、よくわかんないけど
/html/ にいれちゃえ……。
と、当然のようにインストーラも立ち上がらず（＊）、エラー。
＊いや Legacy じゃないんだから、立ち上がるはずはないだろうと思いつつも、
じゃあ、phpMyAdmin でなにか table を作っておくってことなのかしら？？
> 今回の場合は構造になってくると思います。
なるほど。了解です！
> アーカイブのサンプルはフリーのテンプレートを拾ってきて
> 技術者向けにタスクシステムとレンダーシーケンスを解説するサンプルになっ
> ているのですが、
まず、ここにたどり着けていないですね、ぼく。
> XOOPS2 のようにブロックやコンテンツを実際に配置するのは少し厳しいテン
> プレートばかりなので、
> そういった CMS での機能立証ができるような検証用のテーマの一連のセット
> が欲しいなと思って公募を出しました。
<?php if (isset($vars['bufferMap'][XCUBE_RENDER_SEQUENCE_1])) foreach ($vars['bufferMap'][XCUBE_RENDER_SEQUENCE_1] as $buf) { print $buf; } ?>
とか書いてあるので、Smarty じゃないことはわかりました。
＃Smarty でないことは、たぶんそれほど問題ではないんですが。
なんというか、「何が動くがよくわからないけど、脳内レンダリングで、
こういうような html を書く」ってのはもしかしたら、できるのかもしれません。
> XOOPS2ではブロックのアサインが５つのプレースホルダ、コンテンツの
> アサインが一箇所で固定でしたが、今後はここは動的になります。
ふんふん。
> そういったことの検証と、
> あとは、のちのちテーマやテーマのスタイルが検証しやすいように、
> xoops.css 的なものの作成ですね...
まあでも、構造が先ってことですね。
> （といっても換装ができなかった XOOPS とは全然違うし、
> 作っていただいたものも最終的にはサンプルとして収録するだけになると思います
> なので気楽にやってくださいませ）
僕は本業ウェブ屋で、XCL に関しては、サイトを作ってて楽しいということは
下地にあるものの、ああなってほしい、こうしたいな、トカ、どうしても下心を
なくしきれないんですが、こっちのお話は雑念なしでヘネモネやっていけそうで
興味あります。
ハシゴ掛けておいてもらって、その上でさらに甘えてしまうんですが、
まだ届かなかったんで、どうか踏み台もお願いします～ m(._.)m
minahito
なんかもうちょっと用意します＞ minahito sandbox
すみません、今夜はもうタイムオーバー (^^;;
デザイナーさん向けというより技術者さん向けですが、
XOOPS Cube コア側で新たに統一的に実装される汎用レンダーシーケンスに
ついて既存の説明とは切り口の違う説明をひとつ作りました。
http://sunday-lab-ja.blogspot.com/2008/03/diff-between-xc-and-xclx2-render.html
あとでプロジェクトの Wiki のなにかのドキュメントとマージします。
08/03/12 に JIDAIKOBO SHIBATA Nobufumi<jida...@gmail.com> さんは書きました:
--
minahito (mina...@gmail.com)
JIDAIKOBO SHIBATA Nobufumi
On Thu, 13 Mar 2008 00:45:50 +0900, minahito wrote:
> すみません、今夜はもうタイムオーバー (^^;;
おつかれさまでっす。
> デザイナーさん向けというより技術者さん向けですが、
> XOOPS Cube コア側で新たに統一的に実装される汎用レンダーシーケンスに
> ついて既存の説明とは切り口の違う説明をひとつ作りました。
> http://sunday-lab-ja.blogspot.com/2008/03/diff-between-xc-and-xclx2-render.html
僕自身はデザイナの仲間にも技術者の仲間にも入れないコーモリなんですが、
上記エントリを拝見して、ちょっとですが（＊）、昨日より自分のなかのイメージが
豊かになりました。
＊minahito さんの記事がわかりにくいせいで理解度がちょっとなのでなく、
こっちの問題です、くれぐれも。
というわけで、
> なんかもうちょっと用意します＞ minahito sandbox
現時点で追いきれていないのは、すこし申し訳ないんですが、
でも楽しみにさせていただきますです :-)
minahito
昨日、ある程度下地を整えておきました。
サンプルにもアクセスしやすいように index.html とか作ったりしました。
Smarty RenderSystem も追加しておきました～ (^^)/
しかし午前中しか時間が空いてなくて、アーカイブするところまではいたらず... orz
> > 今回の場合は構造になってくると思います。
> なるほど。了解です！
たぶん話としてはまさにコレだと思うんです:
http://xoopscube.jp/modules/xhnewbb/viewtopic.php?topic_id=5781&viewmode=flat
XOOPS2 のときは table ベースがダメだダメだといわれつつも、
CSS が基本的に改定されず、モジュール開発者にとっての HTML タグの作り方の
レギュレーションが変化しなかったため、ある意味プログラマには分かりやすかった
のですが、
今後 CSS が新たにイチから作られ、テーマフォーマットも未定を受け入れる仕様に
なると、
1. モジュール開発者がアレなモジュールやコレなモジュールを作るときにどう書けば
いいのか
2. テーマスタイルの入れ替えが可能という仕様に対して、モジュールはどうリソースを
抱えていくのか？
（テンプレートファイルを複数格納するのか？いっそネット越しにテンプレートセンターみ
たいなところからデータをもらってくるのか？）
といったことを決めていかなくてはいけません。
今回の XOOPS Cube は上記のテーマ未定に関して技術的なアタリはつけています。
あとは人間がどう使っていくか、どうデータを作っていって、どう持っていって、どう配って
いくのかを決めていかないといけません。
さらに XOOPS は特性上、 Web 業界"外"のプログラマがかなり精力的に活動して、
多くの成果物をリリースしているという事実もあるので、CSS とか言われてもチンプン
カンプンな開発者に示せるドキュメントの整備とか
（厳密に言うと、今後複数のフォーマットが出てくるわけだから、そういうフォーマットの
提示者が提示するドキュメントの雛形のようなもの）
も必要になってくると思います。
XOOPS2 に合わせればよかった Legacy と異なり、デザイナーさんにもどんどん入って
ガリガリやっていただきたいと思っています。
（そもそもこの仕様自体がデザイナーさんが熱望されていたことだと思いますので）
「唯一仕様」を決めるわけじゃなくて、
「今後多数出てくる仕様を作る人へ向けてのレギュレーション作り」
なので、いっぱいいろんな人が入ってきて色々作って、
きつくなったら統合して……とか自由にやっていただければと思います。
08/03/12 に JIDAIKOBO SHIBATA Nobufumi<jida...@gmail.com> さんは書きました:
>
--
minahito (mina...@gmail.com)
JIDAIKOBO SHIBATA Nobufumi
On Fri, 21 Mar 2008 12:49:39 +0900, minahito wrote:
> 昨日、ある程度下地を整えておきました。
> サンプルにもアクセスしやすいように index.html とか作ったりしました。
> Smarty RenderSystem も追加しておきました～ (^^)/
おつかれさまです～。んが、
> しかし午前中しか時間が空いてなくて、アーカイブするところまではいたらず... orz
アーカイブに至ってない、ということから、
http://sourceforge.net/project/showfiles.php?group_id=159211
には、ないんだろうとおもい、はじめての CVS で checkout してみたんですが、
どうもそういうことでもないんですかね？
http://xoopscube.cvs.sourceforge.net/xoopscube/XCube_PHP4/samples/simple01_smarty/
ってのがあるのが、「Smarty RenderSystem」の受け皿でしょうか？
> たぶん話としてはまさにコレだと思うんです:
> http://xoopscube.jp/modules/xhnewbb/viewtopic.php?topic_id=5781&viewmode=flat
トピック主がいっていることは、サイトを維持していくときに自然に
Valid なコンテンツにしていきたいってことですよね？
たとえば、掲示板にヘネモネ書き込んでも、きちんと Valid になるし、
コンテンツ作成モジュール的なものに書き込んでも Valid が維持されていく。
CMS というか XOOPS 的な解決だと template のつくりかたの問題なのかなと
思うんですが、これはちょっと横においておいて（オイ）。
ちょっと指差し確認しながらついていかせてくださいね。
> XOOPS2 のときは table ベースがダメだダメだといわれつつも、
table でつくられた theme はたしかにちょっと、って言われていましたね。
> CSS が基本的に改定されず、モジュール開発者にとっての HTML タグの作り方の
> レギュレーションが変化しなかったため、ある意味プログラマには分かりやすかった
> のですが、
table テーマがあまり支持を得ていなくても、モジュール開発者は、実質
いろいろなルールを気にせずにテンプレートを作っていた（作れた）
ということですよね。
> 今後 CSS が新たにイチから作られ、テーマフォーマットも未定を受け入れる
> 仕様になると、
「テーマフォーマットが未定」というのは、どんなテーマに自分のモジュールが
のるのかはわからないよ、ってことですよね？
あるいは「フォーマット」って言葉がもっと奥の深い言葉だとすると、
これも言葉の取り方があっておるのか、なんだか自信ないのですが、
さらにおいておいて、
「CSS が新たにイチから作られ」というのは、ちょっとキモなんですが、
たとえばこんなのを書いてみます。
p.XC_error {
color: #900;
background-color: #eee;
font-weight: bold;
border: 1px #900 solid;
}
たとえば「フォームに入っているべき文字が入ってないよ」とかいうエラー
を返すときに、この p にいれましょう、というようなことを決めるのが、
「CSS を」新たにイチからつくる、ってことでしょうか？
となると、minahito さんがいま求めているのは、こういった「CMS に
どんな機能があるのかを想像しておいて、その CSS のクラスを
作っておく」というようなことでしょうか？
でも、そういう理解だと、
> 「唯一仕様」を決めるわけじゃなくて、
> 「今後多数出てくる仕様を作る人へ向けてのレギュレーション作り」
と矛盾するような気もしたりして……
さらに、これって CSS を新たに作るっていう発送じゃないですよね。
CMS の持つ「場面（？）」をたくさん想定するってことですよね。
なんかね、manifesto の件とか、Wii のデモとかですね、
目指しているものは断片的にわかっているつもりなんですが、
うがー、ちくしょー！ スンマセン、結局、ワケわかってないっす T_T
レベル３なのにワードナと戦ってるみたいな気持ちっス。
というわけで、XCDM#02 やってください。絶対いくので。
minahito
> アーカイブに至ってない、ということから、
>
> http://sourceforge.net/project/showfiles.php?group_id=159211
>
> には、ないんだろうとおもい、はじめての CVS で checkout してみたんですが、
> どうもそういうことでもないんですかね？
おおお
CVS で落とせるようであれば XCube_PHP4 の minahito_sandbox ブランチを
チェックアウトしていただければ最新をゲットできると思います。
README にありますが、もしチェックアウトできたら
それを htdocs などに展開して
http://localhost/XCube_PHP4/samples/
にアクセスすればサンプルプログラムのインデックスにたどり着けます。
（単体で動作します）
> ちょっと指差し確認しながらついていかせてくださいね。
はい
すみません説明がアレで (つoT)
> > CSS が基本的に改定されず、モジュール開発者にとっての HTML タグの作り方の
> > レギュレーションが変化しなかったため、ある意味プログラマには分かりやすかった
> > のですが、
>
> table テーマがあまり支持を得ていなくても、モジュール開発者は、実質
> いろいろなルールを気にせずにテンプレートを作っていた（作れた）
> ということですよね。
はい、 CSS は XOOPS2 では整備されていなかったし、
タグは分かりやすかったのでプログラマには何をすべきか分かりやすかった
という面は大きかったと思います。
> > 今後 CSS が新たにイチから作られ、テーマフォーマットも未定を受け入れる
> > 仕様になると、
> 「テーマフォーマットが未定」というのは、どんなテーマに自分のモジュールが
> のるのかはわからないよ、ってことですよね？
はい、そのとおりございます。 m(__)m
> 「CSS が新たにイチから作られ」というのは、ちょっとキモなんですが、
> たとえばこんなのを書いてみます。
>
> p.XC_error {
> color: #900;
> background-color: #eee;
> font-weight: bold;
> border: 1px #900 solid;
> }
>
> たとえば「フォームに入っているべき文字が入ってないよ」とかいうエラー
> を返すときに、この p にいれましょう、というようなことを決めるのが、
> 「CSS を」新たにイチからつくる、ってことでしょうか？
はい、それが「テーマフォーマット」になっていくと思います。
> となると、minahito さんがいま求めているのは、こういった「CMS に
> どんな機能があるのかを想像しておいて、その CSS のクラスを
> 作っておく」というようなことでしょうか？
です。
というより、そういう作業を通じて「最適解を探し出す」検証作業になるかと
思います。
「CMSにどんな機能があるのかを想像しておいて、そのCSSのクラスを作って
おく」
というのはどう考えても限界があると思います。
しかし、それ以外ぱっと思いつかないのも事実でして、実際にそういうところから
初めてみて、
「これは無理だ」
「これなら行けるかもしれない」
という方法論を探し当てていきたいというのが本音です。
> > 「唯一仕様」を決めるわけじゃなくて、
> > 「今後多数出てくる仕様を作る人へ向けてのレギュレーション作り」
>
> と矛盾するような気もしたりして……
これはですね、、、
XOOPS Cube が想定しているスペックは
「テーマフォーマット……CMS体系自体が差し替えられる」
「しかし新たなフォーマットを作るものは開発者にその指針を示さなければ
ならない」
というのがありますが、
「完全に自由」だとかえって何をしたらいいのか分からない、ということが
あると思うんです。
たとえば XOOPS2 はボロクソにいわれましたけど、ボロクソに言われるとい
うことは「そうはいっても動くたたき台」としての役割を完璧に果たしたとい
うことだと思うんです。
「俺だったらこうする」というのは誰にも思いつくけど、
「ゼロからこうする」というのはなかなかどうして手が動かないらしい。
僕のいうレギュレーション作りというのは、スペックのレギュレーションでは
なく、「自由度の高いゲームにおける最初に提示された必勝法」くらいに思っ
てください。
それを仕様として強制する訳ではなく、第一経験者としてガイドラインを示す
ということです。
ソフトウェアの仕様としては自由度が非常に高いので、
「もしテーマフォーマットを新たに提唱してみたいならこうしてみましょう」
というガイドラインを示すような形です。
その最終形が自分にも想像できないので (^^;
「とりあえず考えられるパターンを全部作るところからお願いします m(__)m」
となっているのです。
たぶん最終的にはテーマフォーマット（CSS)とモジュールの組み合わせの
テンプレートは、ネットワーク越しにテンプレートバンクのようなところから
ダウンロードしないとやっていけないのではないかとは思っています。
最終的にこの公募を通じていろいろなことが議論され、
そういったことを検証するための開発活動につながっていくことを期待しており
ます。
> というわけで、XCDM#02 やってください。絶対いくので。
これやりましょー是非 (^^)b!!
--
minahito (mina...@gmail.com)
JIDAIKOBO SHIBATA Nobufumi
On Tue, 25 Mar 2008 01:05:55 +0900, minahito wrote:
> CVS で落とせるようであれば XCube_PHP4 の minahito_sandbox ブランチを
> チェックアウトしていただければ最新をゲットできると思います。
cvs -z3 -d:pserver:anon...@xoopscube.cvs.sourceforge.net:/cvsroot/xoopscube co -r minahito_sandbox -P XCube_PHP4
で、とれました～。
僕が悪いんですが、この一歩は小さな一歩ですが、
それにしても時間のかかる一歩でした ^^;
もしかすると後の人に役立つかもしれないので、
続けて、やったことを書いておきます。
で、MAMP に 添付のような感じで突っ込んで、localhost/XCube_PHP4/
にアクセスすると、やさしく index.html が迎えてくれました！
JIDAIKOBO SHIBATA Nobufumi
コレ忘れてました。
すぐに minahito さんがアーカイブを作られると思うのですが、
もし興味のある人がいたら、と思いアップしておきます。
http://www.jidaikobo.com/xoops/XCube_PHP4.zip
＊ ＊ ＊
minahito さん、ハシゴ掛けに踏み台設置までありがとうございました。
ようやく議論に追いつけそうな気がしてきました。
On Tue, 25 Mar 2008 01:05:55 +0900, minahito wrote:
>> となると、minahito さんがいま求めているのは、こういった「CMS に
>> どんな機能があるのかを想像しておいて、その CSS のクラスを
>> 作っておく」というようなことでしょうか？
> というより、そういう作業を通じて「最適解を探し出す」検証作業になるかと
> 思います。
「作業を通じて最適解を探し出す」という部分を読み飛ばしちゃうと
マズい文章理解になっちゃいそうですね。
＃というか、ようやく触れそうな段になったので、あらためてこのスレッドを
読み返してみたんですが、よくみると、なんども minahito さんに同じ説明を
させていますね……。まったく申し訳ないです m(._.)m
本来、CSS は「飾り」担当で、でも本質部分（＝構造）担当の HTML を
さしおいて、あえてここからキメていこうというのは、一見、順番が
おかしいようにも思いますが、ところがどうして、class 名が HTML の
構造表現力の足らない部分を補っているので、こういう考え方で
アプローチしてみたらどうじゃろ、ということですよね？
で、あと、実験次世代テーマだし HTML5 とか言っちゃってもいいじゃろ、と。
とりあえず、前提を共有するところまでくることができたという確認の意味を込めて
一通お送りしておきます。
ちなみにギガマスさんが反応しておられますね。
http://sourceforge.net/forum/forum.php?thread_id=1960794&forum_id=537172
いくつかギガマスさんなりに UI を検討されたようですね。
でもって、そのうち現物持ってくるよ、というかんじでしょうか。
というわけで、今日のところは取り急ぎ～
minahito
ぐわー手間をかけさせてしまってすみません。
CVSの操作に関してはGUIクライアントを使うのが楽だと思います。
.org には古いリポジトリながらも説明があるのですが、
http://xoopscube.org/modules/pukiwiki/index.php?cmd=read&page=XOOPSCubeLegacy%2FCVS&word=CVS
sf.net Wiki には移ってないので暇を見て移しておきます。
> でアクセスすると、んー、Notice がいっぱい出てなんだかわからんなーと、
うぇ!?
なんて出てました？
一応 Notice とかは常に全部潰してるはずなんですが……
08/03/25 に JIDAIKOBO SHIBATA Nobufumi<jida...@gmail.com> さんは書きました:
> samples に進むと、
>
> -Hello world
> -simple01
> -simple01_smarty
>
> となっていますね。あ、細かい話ですが、simple01_smarty のリンク先が
> 間違っていました。
>
> /XCube_PHP4/samples/index.html
> -<dt><a href="./simple01">simple01_smarty</a></dt>
> +<dt><a href="./simple01_smarty">simple01_smarty</a></dt>
>
> でアクセスすると、んー、Notice がいっぱい出てなんだかわからんなーと、
> なったので、とりあえず、/XCube_PHP4/samples/simple01_smarty/index.php
> に、
> error_reporting(0);
> を足してみると、お、なんだかキレー目の雰囲気のページが出てきました。
> ようやく土俵にたどり着けた感じです :-)
>
> そのほかの件については、投稿を改めます。
>
> --
> 以下署名。
> 柴田宣史 - SHIBATA Nobufumi -
>
>
>
--
minahito (mina...@gmail.com)
JIDAIKOBO SHIBATA Nobufumi
On Sat, 29 Mar 2008 10:45:34 +0900, minahito wrote:
> ぐわー手間をかけさせてしまってすみません。
> CVSの操作に関してはGUIクライアントを使うのが楽だと思います。
いやー、別に手間じゃないっすよ。
GUI クライアントについては、SVN では、SCPlugin というのを
重宝していて、CVS もなんかあるかなーとちょっと探したんですが
なんだかキリっと動いてくれるやつがなくって、コマンドラインで
踏ん張ってみました :-)
>> でアクセスすると、んー、Notice がいっぱい出てなんだかわからんなーと、
>
> うぇ!?
> なんて出てました？
> 一応 Notice とかは常に全部潰してるはずなんですが……
こんなかんじでゲス。
▼ここから────────────────
Notice: Undefined property: XCube_Task::$mIsInitialize in /***/core/XCube_Task.class.php on line 39
Notice: Undefined property: BaseTask::$mIsInitialize in /***/core/XCube_Task.class.php on line 55
Notice: Undefined property: XCube_Task::$mIsInitialize in /***/core/XCube_Task.class.php on line 39
Notice: Undefined property: XCube_Task::$mIsInitialize in /***/core/XCube_Task.class.php on line 129
Notice: Undefined property: BaseTask::$mIsInitialize in /***/core/XCube_Task.class.php on line 129
Notice: Undefined property: BaseTask::$mIsInitialize in /***/core/XCube_Task.class.php on line 39
Notice: Undefined property: LeftTask::$mIsInitialize in /***/core/XCube_Task.class.php on line 55
Notice: Undefined property: BaseTask::$mIsInitialize in /***/core/XCube_Task.class.php on line 39
Notice: Undefined property: LeftTask::$mIsInitialize in /***/core/XCube_Task.class.php on line 129
Notice: Undefined property: MainTask::$mIsInitialize in /***/core/XCube_Task.class.php on line 129
Notice: Undefined property: NothingTask::$mIsInitialize in /***/core/XCube_Task.class.php on line 129
Notice: Undefined property: XCube_RenderOperation::$mAttribute in /***/core/XCube_RenderTargetQueue.class.php on line 208
Notice: Undefined property: XCube_RenderOperation::$mAttribute in /***/core/XCube_RenderTargetQueue.class.php on line 208
────────────────ここまで▲
minahito
> こんなかんじでゲス。
ギェー 情報サンクスです。
さっそく見てみます。
> GUI クライアントについては、SVN では、SCPlugin というのを
> 重宝していて、CVS もなんかあるかなーとちょっと探したんですが
> なんだかキリっと動いてくれるやつがなくって、コマンドラインで
> 踏ん張ってみました :-)
なんと (つoT)
僕も CVS は CVS クライアントとして Eclipse を使うことが多いです。
実際これが一番使いやすいような気がします。 (^^;
よその OSS も CVS 使ってるケースが少なくないですからね～
# ウチらも CVS コンベンションのような運営規約を進める上で
# 権限設定ができない SVN に移れない
08/03/29 に JIDAIKOBO SHIBATA Nobufumi<jida...@gmail.com> さんは書きました:
--
minahito (mina...@gmail.com)
minahito
先週からようやくまとまった時間が再び取れるようになってきたので、いろいろ手を出していたのですが、
やはし、検証していくうえで BASE をひとつ作ったほうがよい気がしてきました。
それで jidaikobo さん申し訳ないのですが、
mac お持ちだったと思うので、体験版で構わないので一度 RapidWeaver という CMS をチェックしてみて
いただけないでしょうか？
前々から eZp （あるいは MODx）のような Tree 型のサイト管理コアと、 Nuke のよいところ（型にはまら
ないところ）を両立できないかなぁと思っていて、動的ではないですがそのバランス感に近い
Rapid に注目していました。
テーマに関しても、今回の「次世代テーマの作り方の模索」みたいなのに近いものを持っていると思います。
「モジュールは追加されるのに、テーマはどうやって HTML 持つのよ」
みたいな。
Mac OS X お持ちでなければ、
日本代理店のアクトツーさんのところからオンラインマニュアルを入手できますので、
これを有難く見させていただきましょう (-人-)
http://www.act2.com/help/rapidweaver3_5/index.html
http://www.act2.com/products/rapidweaver/manual.zip
開発中のブランチは覗かなければ動きが分かりづらいので、ジョインもしてもらいづらいので、
なんか考えます。
（というか、なんか考えてください誰か;;）
--
minahito (mina...@gmail.com)
JIDAIKOBO SHIBATA Nobufumi
On Sat, 17 May 2008 12:53:15 +0900, minahito wrote:
> mac お持ちだったと思うので、体験版で構わないので一度 RapidWeaver という
> CMS をチェックしてみていただけないでしょうか？
さっき体験版を入れて、すこしいじってみました。
> 前々から eZp （あるいは MODx）のような Tree 型のサイト管理コアと、
> Nuke のよいところ（型にはまらないところ）を両立できないかなぁと思っていて、
> 動的ではないですがそのバランス感に近い Rapid に注目していました。
eZp とか触ったことがなくって、ちょっとわからない所もありますが、
Rapidweaver は、ブログとかギャラリーとか、いわゆるプラグインアイコンが示す通り、
拡張できそうな感じになっているんですね。
> テーマに関しても、今回の「次世代テーマの作り方の模索」みたいなのに近い
> ものを持っていると思います。
> 「モジュールは追加されるのに、テーマはどうやって HTML 持つのよ」
> みたいな。
次世代テーマの件、minahito さんのメールをぼくのメーラではずっと未読にして、
未解決にしてあります（だからなんだといわれそうですが ^^; ）。
流れを止めてしまったせいで、しょんぼりさせたかもしれませんが、
もちょっとだけお待ちくださいませ～。
＊ ＊ ＊
rapidweaver のテーマインスペクタをいじってて思ったんですが、
HD にはいってる hd_default には、ちょっと似たものがあるんです。
以前、ちらっと minahito さんにみせていただいた rapidweaver の画面で
印象に残っていたので、theme_config.dist.php ってのをつくったんです。
まあ、まったくもってユーザフレンドリーな何かではないので、
アレなんですが……。
minahito
> eZp とか触ったことがなくって、ちょっとわからない所もありますが、
> Rapidweaver は、ブログとかギャラリーとか、いわゆるプラグインアイコンが示す通り、
> 拡張できそうな感じになっているんですね。
はい、 eZp はすべてのコンテンツをサイトツリーのノードとして拡張するのですが、
クラスという考え方があって、「ブログのエントリはタイトルと本文と入力日と……」
みたいなデータの型を動的に決定できる点が強力です。
それゆえに、フォーラムやブログもその組み合わせで作る必要があり、ツリーが下に延び
まくって、かつ、むちゃくちゃ管理しにくいのです。
http://sunday-lab-ja.blogspot.com/2008/04/supplement-to-rapidweaver-gives-hints.html
その仕組みすべてで多言語レイヤーや権限解決が使える点はさすがに元数百万クラスの
商業 CMS だ！という感じですが、 XOOPS のようにフォーラムやニュースを設置して
みんなでわいわい！というサイトは作りにくいです。
なんにせよ XOOPS のようにモジュールを水平展開しかできない、というわけではない
ので、ニュースの下にフォーラムを入れるなど、ウェブサービスの配置と URL のあり方
を一致させられるというメリットはあります。
RapidWeaver はそれを組み合わせた感じで、
ブログやギャラリーを作る際に、管理上、子ノードは発生しません
（eZp だとエントリやギャラリーの写真を子ノードとして作ってしまう
１枚の写真で１枚のページを作ってしまう）
イメージ的には XOOPS の複製機能にツリー配置を組み合わせたような感じです。
（D３で複製した pico の下に pical が置ける）
したがって、ブログAとブログBの間でデータの移動はできません。
ただ、静的コンテンツ系は１コンテンツ＝１ページとして扱う形になると思います。
pical とかはそのままの考え方で持って来れるけど、
pico の場合は pico をノードに配置してその管理機能で記事を作るという考え方と、
Rapid の「スタイルつきテキスト」のように１ページ１ノードで記事を作るという
考え方の両方を実践できるようになります。
> 次世代テーマの件、minahito さんのメールをぼくのメーラではずっと未読にして、
> 未解決にしてあります（だからなんだといわれそうですが ^^; ）。
> 流れを止めてしまったせいで、しょんぼりさせたかもしれませんが、
> もちょっとだけお待ちくださいませ～。
いえ、気にしないでください。(^^;
というより、あれから色々考えて、やはり BASE の開発なくしてテーマの模索は
無理だなと思うようになりました。
ということで簡単な BASE 作りましょう (^^;;
> rapidweaver のテーマインスペクタをいじってて思ったんですが、
> HD にはいってる hd_default には、ちょっと似たものがあるんです。
> 以前、ちらっと minahito さんにみせていただいた rapidweaver の画面で
> 印象に残っていたので、theme_config.dist.php ってのをつくったんです。
> まあ、まったくもってユーザフレンドリーな何かではないので、
> アレなんですが……。
なるほど弄ってみます！
もちろん HD は HDD に突っ込んであります。
あと Rapid で面白いのはメニューかなぁ……
ツリー展開すると、どうしてもメニューをどう扱うかが問題になってくるのですが、
Rapid の場合はもともとテーマに最大３階層までの全記事タイトルとURLを供給する
仕組みになっていて、それをどう組み込むか:
- XOOPS のようにまずトップ階層のリンクを出して、あとはその中に入っている
場合は子のリンクを展開する
- JavaScript を使ってマウスオーバーメニューにしてしまう
ということがテーマ側の実装で決まるようになっています。
マウスでぐりぐりドラッグして、コンテンツの配置をいろいろ組み替えることができる
からこそ、本当はユーザーにとって理想の誘導やメニューの出し方というのがあると思
うんです。
しかし、 Rapid は、
「３階層までメニュー側で直リンクしてしまえばたいていのサイトで間に合うだろう」
と完全に割り切っています。
この落とし方がものすごく目から鱗でした。
で、テーマ側でそれが実装できるため、つねにメニューはテーマにビルトインなので、
メニューの扱いに色々不満があったとしても、テーマとうまく融合したメニューを見
れば、まぁいいかという気分になってきます。(^^)
もちろんちゃんとした仕事ではきついでしょうけど、
単にそれなりのものが設置できれば良いユーザーレベルではまったく問題にならない
仕様です。
ソースが公開されていないので、カスタマイズしたくてもできないのが問題なくらい？
--
minahito (mina...@gmail.com)
minahito
RapidWeaver の最新版４の紹介ビデオがありましたので紹介します。
http://www.realmacsoftware.com/rapidweaver/quicktours/
テーマインスペクタの操作の部分は動画になく、ブログやアルバムの操作もありませんが、
マニュアルとあわせて、おおむね雰囲気は掴めると思います。(^^)
--
minahito (mina...@gmail.com)
JIDAIKOBO SHIBATA Nobufumi
RapidWeaver4 の movie をみてみました～。ご紹介ありがとうございます。
3 からは無償アップデートとのことですが、なんと leopard 用だったんですね ^^;
まあ、インタフェイスのグレードアップはあるようですが、もちょっと
Tiger で踏ん張りそうなので、もちょっと RapidWeaver3 をみてみます。
ではでは、
JIDAIKOBO SHIBATA Nobufumi
もしかすると、もうスレッドを改めた方がいいのかなーとも思いつつ。
minahito さんとお話ししてた、「交換可能なテーマのプチ改造」
について遊んでみたので、投稿させてください。
まずアピアランス形成の順番の件ですが、
１、モジュールが見栄えと構造を提供する（モジュールのCSSとテンプレート）
２、テーマはモジュールのCSSをオーバライドできる（テーマのCSS）
３、テーマプリロードは最終的な出力にオーバライドできる
みたいなかんじですよね？
２ができないとテーマ作家は楽しくないですし、３がなかったらテーマの
pokemonize ができないですよね。
でもって、３の段階では、XCL だったら $xoops_contents にあたる部分、
できればそのほかのブロックやらなんやら、あるいは出力全部を乗っ取れないと
真の pokemonize になりにくいですよね。
出力全部を乗っ取るのについては、別案なくはないのですが、
そんなこんなを XCL だったらどないやろ、と遊んでみました。
http://www.jidaikobo.com/xoops/080819_theme_preload.zip
このファイル群だけでは何もできないんですが、hd の hd_default で
やってみたスクリプト例です。
テーマ先頭で、テーマプリロードの存在を確認して、
ルールに沿った所与の関数名の関数があったら、たとえば HTML の
header を足したり、block や xoops_contents をいじれる、
というようになっていると思います。
危ないスクリプトだとか、そのあたりはちょっと措いておいてなんですが、
要はテーマプリロードみたいなのだと、やっぱり配布はフォルダを圧縮して
という感じなのかなーと思っています。
１ファイルで無理矢理やっちゃうのは CSS までだったらできるんですが、
たとえばテーマプリロードでロゴを乗っ取っちゃえ……とかしたかったら、
どうしても画像を同梱する必要が出て来ちゃうし仕方がないかなーと、
そんなこんなで尻切れとんぼの投稿ですが、おおくりします。
minahito
すみません、さしあたって下記の部分のみご返信申し上げます。 m(__)m
> １、モジュールが見栄えと構造を提供する（モジュールのCSSとテンプレート）
> ２、テーマはモジュールのCSSをオーバライドできる（テーマのCSS）
> ３、テーマプリロードは最終的な出力にオーバライドできる
僕は、
２、テーマプリロードは、特定のテーマとモジュールの組み合わせの際に、モジュールとテーマのテンプレートとＣＳＳをパッチ（オーバーライドできる）
３、テーマは最終的な出力を決める。テーマより強いものはない
（ただし、２を定義していない限り、２のパッチは最終出力に生き残る）
という感じでイメージしていました。
Ａ）モジュール開発者が提供するさしあたってのリソース
Ｂ）テーマ開発者が提供する完璧な見栄えと構造のテンプレートとＣＳＳ
Ｃ）Ｂ）がＡ）に対応できない状況下で、デザインが分かっている人が作るパッチ
という形です。
以下ストーリー仕立てでお送りします。
------------------------------------------------------
第１章
広島県在住のＭさんは、
Ｂ）の人が作ったテーマ「レッド鯉テーマ」を自分のサイトに適用して、
ご機嫌な毎日を過ごしていました。
あるとき、Ａ）の人が開発した新モジュール Digg をダウンロードして、
自分の好きなスポーツチームに関するソーシャルニュースコーナーを追加しました。
しかしＡ）はＢ）のテーマに含まれない「新たなＣＳＳ定義」を持っており、
投票欄のバックグラウンドが "黄色い縦縞" だったのです。
しかも悪いことに投票数がちょうど２５に！
「なんでわしのサイトで縦縞の２５を見なきゃいかんのじゃ！」
Ｍさんは怒りました。
怒ってＢ）の人に、
「頼むけえ、Ｂ）テーマで、Ａ）モジュールの暫定デザインをレッド鯉テーマに
沿ったデザインで表示できるようにしてくれ！」
とメールしました。
しかしＢ）の人は、
ドジャーズ黒田の試合を見にロサンジェルスへ旅行へ出かけていたのでした。。。
------------------------------------------------------
僕の考える第２章はこんな感じです。
------------------------------------------------------
第２章
Ｍさんは困って XOOPS のコミュニティサイトに投稿しました。
「何とかしてください！」（←悪い例）
困ったＭさんのために、たまたまその投稿を読んでいたＧさんは、
Ａ）のモジュールをＢ）のテーマと組み合わせたときに、
とりあえず黄色い縦縞を何とかするパッチファイルＣ）を作成しました。
Ｇさんも専門のデザイナではありませんので、
黄色い縦縞が、赤い縦縞に変わっただけですが、
パソコンのことがさっぱり分からないお好み焼き屋のＭさんは大助かりです。
「ありがとう！ ほいじゃーね！」
このパッチファイルを規定の位置に格納するか、
ネットワークシステムでダウンロードすることで、見栄えは修正されました。
Ａ）モジュールもどんどんバージョンアップしていきましたので、
何も分からないＭさんも、自動アップデートに従ってどんどん追従していきましたが、
特に大きな問題は起きませんでした。
やがて、ロスからＢ）の人が帰国しました。
メールをチェックしたＢ）の人でしたが、
応援していたチームがプレーオフに出場し、日本シリーズに出場したため、
アジアシリーズに優勝するその日まで、
自由時間のほとんどを野球の応援に費やしてしまい、
Ｂ）のテーマを修正する時間がとれたのは結局数ヵ月後になりました。
そしてＢ）テーマは正式にＡ）モジュールに対応するようになり、
Ｍさんはバージョンアップ版をダウンロードして適用しました。
Ｍさんはパッチファイルのことなんかすっかり忘れて、
抜き忘れていましたが、
テーマは正しく適用され、
Ｍさんは今日もお好み焼きを焼いているのでした。
ちゃんちゃん。
------------------------------------------------------
ちなみにＢ）の「レッド鯉テーマ」を改造して
「パープル三本矢テーマ」を作成する場合は、
この場合、テーマより強いものはないため、
テーマを新作しなければいけません。
（コピペ修正レベルです）
このケースだと、パッチの仕組みはあくまでテーマの不足分を補うもので、
テーマの不具合は修正できないという手順になりますが、これだとあんまり
よくないでしょうか？
（確かにテーマ自体を修正できて、
テーマが対応したら修正ファイルを抜き取る、ほうが対応幅は広いか;;）
--
minahito (mina...@gmail.com)
JIDAIKOBO SHIBATA Nobufumi
悲喜こもごものストーリー拝読しました。
なんとか yet another 第２章を書いて表現しようと思ったのですが、
筆力が追いつかなかったので、フラットに書いちゃいます :-P
On Tue, 19 Aug 2008 09:43:18 +0900, minahito wrote:
> ２、テーマプリロードは、特定のテーマとモジュールの組み合わせの際に、モ
> ジュールとテーマのテンプレートとＣＳＳをパッチ（オーバーライドできる）
> ３、テーマは最終的な出力を決める。テーマより強いものはない
> （ただし、２を定義していない限り、２のパッチは最終出力に生き残る）
僕も最初、テーマが一番強いのがいーかなーと思っていたんですが、
いろいろ考えているうちに、minahito さんが最後に書いておられる事例さえも
pokemonization でやっつけたくなってきたのです。
> ちなみにＢ）の「レッド鯉テーマ」を改造して
> 「パープル三本矢テーマ」を作成する場合は、
> この場合、テーマより強いものはないため、
> テーマを新作しなければいけません。
> （コピペ修正レベルです）
の部分です。
theme が一番強いとすると、theme の style.css を最後に読むことになると思いますが、
「レッド鯉テーマ」のテーマ構造や、同梱オーバライドテンプレートがすぐれていて、
それをいじって再配布、あるいはコードスニペット提供ってのもいいんですが、
「コレ、解凍して /themes/YOURTHEME/preload/ に入れたら、ロゴもさし変わって
背景もかえられるヨ」ってのがやりたい気がするんです。
ロゴ変えようと思ったら、作りにもよりますが、css だけじゃあなくって、
がっちりいじりたくなります。ので、いまから乱暴なことを書きますが、
あくまで思考実験として読んでください。
１、プログラムのいろんな処理を経過して、テーマの番がやってくる
２、まずはテーマプリロードを確認して、$xoops_content やブロック
（にあたるもの）を、そっと手渡してくれる。
３、２で、がちゃがちゃさせてもらったものを、html のヘッダなんかと
たして、$fulldata みたいにして、それも、
また出力前にプリロードに渡してくれる。
３だけでもいいように見えますが、やっぱり２をやりたいなあ。
もうちょっと別の方向から書いてみますね。
今回の例で、Gさんが、Mさんのために、preload を書いてあげる規模のことだったら、
たぶん（「縞模様を既存の赤に変える」くらいだったら）、コードスニペットが
ちょうどいいくらいに思われる、たぶん theme に一行書くだけでしょう（まあ
それもお好み焼き屋さんの M さんにとってすれば、当座なんとかしてくれる
G さんのプリロードファイルの方がいいのはわかるのですが、プリロード最強だったら
どっちも不可能ではないですし）。
が、もしレッド鯉チームが巨大な IT 企業に買収されて、ロゴが変わったら、
……ファンが減るか ^^;
＊ ＊ ＊
くれぐれも、倒して我を通そうという議論のつもりでなくって、
よりよいものをつくる為の議論のつもりなので、ガンガン相対化してくださいまし。
minahito
> theme が一番強いとすると、theme の style.css を最後に読むことになると思いますが、
> 「レッド鯉テーマ」のテーマ構造や、同梱オーバライドテンプレートがすぐれていて、
> それをいじって再配布、あるいはコードスニペット提供ってのもいいんですが、
> 「コレ、解凍して /themes/YOURTHEME/preload/ に入れたら、ロゴもさし変わって
> 背景もかえられるヨ」ってのがやりたい気がするんです。
これは RapidWeaver でいうところの Style みたいなやつですね。
そういうのは凄くやりたいですよね。
Style は話に出したいと思っていたので、
「デザインが分かっている人がテーマの新しい可能性を引き出すためのデータを提供し
Ｍさんは適用するだけで済む」
というものをこのまま Style と呼ぶことにしますが、
個人的には Style と Patch は分けたほうがいいような気がします。
Patch: フリーソフト活動特有の忙殺未対応状況のワークアラウンド・メカニズム
Style: 既存の成果物を調整して新しい可能性を生み出す創作的活動のメカニズム
メカニズム的には Theme の後に働く力があれば、修正と拡張の両方を実現することが
できるという話は分かります。
ただ、 Style が「創作的活動」のメカニズムであることに対して、
Patch はあくまで（日本における）オープンソース活動のフォローアップのためのメカ
ニズムだと、僕は思います。
それを一緒にするとプログラムや構造的にはすっきりしますが、
Ｍさんに Style と Patch の意味合いを自力管理させることを意味しています。
同時適用したときの強弱の調停や、切り替えも、Ｍさんの理解力にかかってくるという
わけです。
それをＭさんに求めるのは無理なので、
いずれ "分かってる人" 同士で、優先度設定を行わなければいけないときがくると思います。
それなら初めから単位として分けたほうがいいのでは...というわけです。
「Patch は絶対に Theme より弱い」「Style は絶対に Theme より強い」であれば、
「ＭさんＢ）の人が帰国するまで Patch で凌いでね」
「Ｍさん Style 入れるともっと楽しくなるよ」
で使い分けることができます。
「おじいちゃん、こっちの白いカプセルは Patch だからね」
「おじいちゃん、こっちの白いカプセルは Style だからね」
といってもおじいちゃん分かんない。
テーマのコピー新作もあなどれなくて、
「レッド鯉テーマ」と
「パープル三本矢テーマ」は、
構造的にどうだろうと、Ｍさん的には別テーマでしょうから、
テーマを新作する意味もすごくあると思います。
というのは、テーマの選択画面でふたつのテーマが並ぶからです。
これはかなり大事じゃないかと僕は思うんです。
特に CSS ドリブンになる場合、
スタイルで弄れる範囲を割ときっちりしておかないと、
テーマを選択した上で、テーマの中でスタイルを適用すると、まったく
別物の "テーマ" になってしまう可能性もあります。
"分かってる人"には「可能性」として面白いものだとしても、Ｍさん的には、
「テーマってなんぞや？？？」
ということになってしまうと思うんです。
Rapid の場合はテーマインスペクタで設定できるパラメータの設定集が Style に
なっていました。この制限は妥当だと思います。
また、頒布時も「パープル三本矢テーマ」だけで単独頒布できます。
プログラムの preload は「コンポーネント結合コード」をファイルにおさ
めて交換しようという考えで、 preload 結合後のアプリケーションを
エンドユーザーが触るというイメージなのですが、
僕はテーマのほうは視覚的なものなので、
「どういう単位で配って」
「Ｍさんはどういう単位で意識して」
「管理画面にどう出て」
「Ｍさんはどこをどうクリックして、どういう最終見栄えを設定するのか」
ということを、きっちり意識したうえでメカニズムを切っていないと
いけないと思います。
Ｍさん的にはレッド鯉テーマもパープル三本矢テーマも選択したいでしょうし。
Patch はもう自動的に当たって欲しいけど。
というわけで、
最終的にモジュールやテーマに採用され、消滅するであろう Patch と、
最後までエンドユーザーの手元に残り、楽しませるであろう Style は、
統合せず、別々のレイヤー（強さ）で扱ったほうがいいというのが、
僕の意見であります。
2008/08/19 10:40 JIDAIKOBO SHIBATA Nobufumi <jida...@gmail.com>:
--
minahito (mina...@gmail.com)
JIDAIKOBO SHIBATA Nobufumi
On Tue, 19 Aug 2008 12:05:03 +0900, minahito wrote:
> 個人的には Style と Patch は分けたほうがいいような気がします。
>
> Patch: フリーソフト活動特有の忙殺未対応状況のワークアラウンド・メカニズム
> Style: 既存の成果物を調整して新しい可能性を生み出す創作的活動のメカニズム
このロジック、かなりがっちりわかりました。詳説ありがとうございます。
Style があるのであれば、僕は楽しみですし、Patch との切り分けも理解可能です。
> テーマのコピー新作もあなどれなくて、
> 「レッド鯉テーマ」と
> 「パープル三本矢テーマ」は、
> 構造的にどうだろうと、Ｍさん的には別テーマでしょうから、
> テーマを新作する意味もすごくあると思います。
ただこっちは諸手を上げて了解ということでなくって、
ちょっと注意深く反応したいです。
・テーマ新作に意味があるのは認めます。
・テーマの選択画面で、テーマが並ぶことの M さんにとっての意味もわかります。
・M さんにとって、「構造」がワケわかんないのもわかります。
・CSS による、構造のプレゼンテーションの分離について minahito さんが
どのように考えておられるかもわかります。
> 特に CSS ドリブンになる場合、
> スタイルで弄れる範囲を割ときっちりしておかないと、
> テーマを選択した上で、テーマの中でスタイルを適用すると、まったく
> 別物の "テーマ" になってしまう可能性もあります。
>
> "分かってる人"には「可能性」として面白いものだとしても、Ｍさん的には、
> 「テーマってなんぞや？？？」
> ということになってしまうと思うんです。
なってしまうのは、想像できます。
注意深く書きたいと言った部分はここなんですが、僕もたいがい minahito さんに
たくさんの説明させているので、次世代テーマあるいは次期 BASE がどういう
ユーザを想定しているかは共有できているつもりですし、
僕もその方向性にのりたいと思っています。
んが、「テーマを選択した上でスタイルを適用するとまったく別物の
テーマになる」というのが、CSS の本懐ですし、その遊び方をしたいです。
だから、もし
> Rapid の場合はテーマインスペクタで設定できるパラメータの設定集が Style に
> なっていました。この制限は妥当だと思います。
……というような「約束」にしようよ、といわれたら、それはヤンタだから、
僕なんかは、わりと最初の段階でこのルールを逸脱しそうです ^^;
＃もともと CSS だけじゃなくって、出力される HTML だっていじりたいと
思っているくらいですから。
でも、もちろん
> 僕はテーマのほうは視覚的なものなので、
>
> 「どういう単位で配って」
> 「Ｍさんはどういう単位で意識して」
> 「管理画面にどう出て」
> 「Ｍさんはどこをどうクリックして、どういう最終見栄えを設定するのか」
>
> ということを、きっちり意識したうえでメカニズムを切っていないと
> いけないと思います。
これはわかるんです。
だから
１、Patch と Style は別レイヤーのものだよ
２、テーマと Style も別もんだよ。
３、管理画面で選ぶのはテーマであって、Style じゃあないよ。
４、でも、（本当は）Style では好き勝手できるよ。
だったら、happily ever after です。
＃まあ、でも想像するにそうなりますよね、きっと。
このメール、あんまり意味のないお返事になっちゃったかな。
＊ ＊ ＊
でもって、ちょっとだけ発情して「テーマインスペクタ」の件なんですが、
次世代テーマで、そんなものがあると面白いなあとは思っていたんですが、
各テーマに「オプション」画面があったら、なんかそれっぽいものできそうですね。
モジュールの xoops_version に書くみたいなやつで、テーマのオプション画面が
つくれて、文字色やメニューの左右、あ、あと言語セット、イメージセット
なんかも選べたりしたら、やっぱり楽しそうですね :-)