汎用DBだれか作りません？
fabi
そのあと実はXCDMにも隠し玉として持っていったのですが時間が余らなかったので発表どころでは
ありませんでした。
（同じテーブルの人は知ってますが。ｗ）
ではDevelopers Group なら話を聞いてもらえるだろうということでここに投げます。
コミュ違いならさっさと引っ込めます。XUGJでもいいかとも思ったんですが、あそこで僕がこういうことを
しちゃうとコミュニティの私物化とも取られかねないのでなかなか難しい。。。
以前から「テンプレートなら作るよ」って話をホダ塾などでしておりまして、汎用DBの良いのが現在無いので、
そこらへんからやっていくのはどうかな？と考えて今企画に至りました。（あ、GIJOEさんのpicoベースDBは
承知してますよ。でも専用モジュールとしても欲しいかなと思ったもので。）
システム絡みの仕事では、先に出来上がったページをコーディングしてそこからシステムを作ってもらう
パターンが多いので、その方法で提案します。
作っていただけるなら誰でもいいです。というかこれをベースに何でもやっちゃってください。
このテンプレートに対してリクエストがあれば再作成、追加ページなど行う用意があります。（時間は
大目に見てね）
名称権も配布権も一切合財（そんな権利があるとして）作ってくれる人にあげます。
ご意見などはとりあえずこのスレッドにください。
詳細などwrapsに組み込んで大体の完成予想イメージを見ることが出来るようにしておきました。
http://cube.undo.jp/
ファイルはここです（テンプレというか普通のHTMLです。）
http://cube.undo.jp/files/mpdb20071117.zip
なんとなくただのクレクレにも思えてきたのですが。申し訳ない。
勘違い野郎だったら言ってください。
このコラボがうまくいくようだったら第二段もあるかも。
（というか初期のホダ塾を大規模に再現したいって事なんですけどね。）
fabi
登録日が項目に入っていなかったorz
tohokuaiki
> システム絡みの仕事では、先に出来上がったページをコーディングしてそこからシステムを作ってもらう
> パターンが多いので、その方法で提案します。
この開発方法は良いですね。
確かにWebページ制作の際にはこういう手順でやりますし。
結局ALTER TABLEを使いまくるのかなぁという気がします。
すると、PHP5なら私の使うORMは自動対応なので、作りやすいかなぁと思いますが。
伊藤
fabi
tohokuaikiさんご反応ありがとうございます。
> 結局ALTER TABLEを使いまくるのかなぁという気がします。
> すると、PHP5なら私の使うORMは自動対応なので、作りやすいかなぁと思いますが。
特にALTER TABLEで可変にしなくてもいいんじゃないかと思います。
現状の仕様の16項目（オプション6項目を含む）は最初からテーブルとして持っておいて、有効・無効は単に入力・修正ページにその項目のフォームを表示
させるか否かを決めるだけにして、フィールドは全部決め打ちにしてしまえば手間がかからないんじゃないかと思いますがどうでしょう。
chika3
On 11月19日, 午前11:41, fabi <minow...@gmail.com> wrote:
> 特にALTER TABLEで可変にしなくてもいいんじゃないかと思います。
> 現状の仕様の16項目（オプション6項目を含む）は最初からテーブルとして持っておいて、有効・無効は単に入力・修正ページにその項目のフォームを表示
> させるか否かを決めるだけにして、フィールドは全部決め打ちにしてしまえば手間がかからないんじゃないかと思いますがどうでしょう。
demo画面的なものであればたぶん流用できそうな感じです。
でもどこまで汎用にするかによって結構難しいですね...
やっぱりALTER使うのがベストなんでしょうが。
fabiさんの考える汎用ってどんな仕様でしょうか？自分的には、
・tiny/int/varchar/text がそれぞれ20-30個以上用意されている
・演算モノはテンプレート側で全部できるように全部渡しておきたい
・項目は管理画面で変更（多言語対応？）
・少なくともD2、できればD3以上対応
・カテゴリー管理ができるもの（結構重要）
なところでしょうか？
p.s. 上のデモ画面でprotectorに引っかかってしまいました。解除してもらえますか？＞fabiさん
gus...@gmail.com
汎用DB、現在開発中なので、そのうち公開できるかと思います。
ただ、fabiさんが出されたアイデア・画面とは全く違う形なのですが・・・。
最終的にはALTER TABLEとか含めた形にしたいと思っていますが、現状だと皆さ
んが想像してる汎用DBとは違う形のものがファーストリリースになりそうです。
fabi
> fabiさんの考える汎用ってどんな仕様でしょうか？自分的には、
>
> ・tiny/int/varchar/text がそれぞれ20-30個以上用意されている
> ・演算モノはテンプレート側で全部できるように全部渡しておきたい
> ・項目は管理画面で変更（多言語対応？）
> ・少なくともD2、できればD3以上対応
> ・カテゴリー管理ができるもの（結構重要）
現状の私の仕様では17～8項目なのでもう少し拡張の必要がありますかね。
・ある程度仕様上に半固定部分が多く、初心者でも利用法が想像できるもの。（項目名などを半固定にしてますが、altsysで名称は変えられる。項目数
は現状固定。）
・テンプレートを変更すれば、いろんなことに流用できそうなこと。基本的にはリスティングとデータの検索抽出を目的とする。
・軽いこと。
・D3であること。
・カテゴリは考え方によると思いますが、既存の物にあるようなデータが必ず「ひとつのカテゴリ」に所属するタイプではなく、複数のカテゴリに所属できる
こと。そのためカテゴリの階層構造は諦めてます。
あとはhttp://cube.undo.jp/ に書いてあるとおりです。
> p.s. 上のデモ画面でprotectorに引っかかってしまいました。解除してもらえますか？＞fabiさん
あれー？誰のIPも引っかかってませんでしたよ。
一応誰かF5アタックをしたようなので（笑）ログも削除しておきました。
fabi
何をもって汎用とするかは利用者の希望によって違いますからね。
私の案も人によっては「どこが汎用なんだよ！」って言われるかもしれません。
とにかく現状Cube対応DBモジュールが手薄なのでバシバシ出せる物は出していきましょうよ。
期待してお待ちしてます。
個人的にはaddbookの延長線にあるようなシンプルな操作性を考えてます。
ITOH Takashi
おそらくですが、あるアイテムを自由に項目付けて表示できるっていう程度かな
と思います。対象は1つのテーブルかと。
私の利用想定では、名簿みたいな感じです。
> ・ある程度仕様上に半固定部分が多く、初心者でも利用法が想像できるもの。
> （項目名などを半固定にしてますが、altsysで名称は変えられる。項目数
> は現状固定。）
> ・テンプレートを変更すれば、いろんなことに流用できそうなこと。基本的にはリスティングとデータの検索抽出を目的とする。
> ・軽いこと。
> ・D3であること。
> ・カテゴリは考え方によると思いますが、既存の物にあるようなデータが必ず「ひとつのカテゴリ」に所属するタイプではなく、複数のカテゴリに所属できる
> こと。そのためカテゴリの階層構造は諦めてます。
fabiさんの挙げた条件では、カテゴリの複数所持が一番大変そうですね。
むしろ階層構造のほうが簡単です。
あと、項目を増減させられないと、作ってて面白くないなーと思います。
なぜなら、項目数が決め打ちなのはいつも仕事で作っているので（苦笑）。
こうだったら面白いかなーと思うのは、ある項目についてフォームのデータが
色々とくっついている感じです。（フォームはActionForm使わないとおそらくキツイ）
ある項目━┳━項目名称
┣━項目の入力方法（テキストエリアとか、セレクトタブとか）
┣━項目の入力オプション（セレクトタブのOption項目とか）
┣━項目の入力デフォルト値
┣━項目のカテゴリ━━━━カテゴリテーブル
┣━項目が必須か？
┣━項目は数字縛りか？
┣━項目にインデックスを張るか
┣..........などなど
こういう「ある項目」を増減できるという感じです。
で、入力フォームを作る際ですが、デザイナーにプレースホルダを提示するか、
自動でくみ上げちゃうのかっていう感じかと思います。
前者の場合、
<{form_input name="item_name" size="***"}>
っていうのが「ある項目」の入力フォームになる。デザイナーはこれ使って
ぺたぺたとテンプレを作っていく感じです。
後者の場合、かのXOOPSFORMのように、フォームがワンセット。
<{$form_table}>
みたいなひとつの変数にレンダリングされてしまう感じです。
で、ALTER TABLEを使わない(項目数きめ打ち)方法だと、ひとつのフィールドにシリアライズして
全部つめちゃうとか。これだと検索とか出来ないですね。
# 項目の増減を諦めるなら問題ないですが
さらに、項目数が決め打ちだと、テンプレ変数が
<{$form1}>
<{$form2}>
<{$form3}>....
とかなって、その後の作業に著しい効率の低下が見られそうです。
伊藤
fabi
むしろ項目は可変の方が効率が良さそうなんですね。
> ある項目━┳━項目名称
> ┣━項目の入力方法（テキストエリアとか、セレクトタブとか）
> ┣━項目の入力オプション（セレクトタブのOption項目とか）
> ┣━項目の入力デフォルト値
> ┣━項目のカテゴリ━━━━カテゴリテーブル
> ┣━項目が必須か？
> ┣━項目は数字縛りか？
> ┣━項目にインデックスを張るか
> ┣..........などなど
>
> こういう「ある項目」を増減できるという感じです。
フォームデザインが難しいですね。
ちょっとどういった形で出来るか検討してみます。
>ActionForm
項目の入力方法（テキストエリアとか、セレクトタブとか）のラジオボタンをチェックした時に、動的にその下の項目が変わらなければならないんですよ
ね。
パターンをいくつか作ってみましょうか。
chika3
On 11月20日, 午後4:36, fabi <minow...@gmail.com> wrote:
> > fabiさんの考える汎用ってどんな仕様でしょうか？自分的には、
>
> > ・tiny/int/varchar/text がそれぞれ20-30個以上用意されている
> > ・演算モノはテンプレート側で全部できるように全部渡しておきたい
> > ・項目は管理画面で変更（多言語対応？）
> > ・少なくともD2、できればD3以上対応
> > ・カテゴリー管理ができるもの（結構重要）
>
> 20-30項目ですか！
> 現状の私の仕様では17～8項目なのでもう少し拡張の必要がありますかね。
ちょっとPHP/MySQLの知識があれば簡単に増やすことができれば、という考えです。
たぶんこれはALTERするしか無いですね(^^;
> ・カテゴリは考え方によると思いますが、既存の物にあるようなデータが必ず「ひとつのカテゴリ」に所属するタイプではなく、複数のカテゴリに所属できる
> こと。そのためカテゴリの階層構造は諦めてます。
サンプルの例だと、自分のいうカテゴリは１つで、別テーブルで種類(TYPE)を使いわける、という感じでしょうか。
複数カテゴリだとweblinks的なものですよね。
> あれー？誰のIPも引っかかってませんでしたよ。
> 一応誰かF5アタックをしたようなので（笑）ログも削除しておきました。
nobu
(xoopscube.org でしかアナウンスしてないな)
http://mysite.ddo.jp/modules/mydownloads/singlefile.php?lid=23
Video 用と言うことにしていますが、構造的には(ここで言われている)汎用のデータベースに
近いと思います。(Video と言っても単なるリンク管理なので、構造はリンク系と同じ)
時田正彦
時田と申します。
便乗しまして、、
もう見てらっしゃるかもしれませんが、汎用データベースモジュール waffle と
いうのを公開しています。
管理ページでカラムを追加すると内部で ALTER TABLE するようになっています。
http://tokita.net/modules/mydownloads/singlefile.php?cid=1&lid=11
ITOH Takashi
nobu wrote:
> ALTER で増減ってーと、こんなモジュールを先日公開してます。
> (xoopscube.org でしかアナウンスしてないな)
>
> http://mysite.ddo.jp/modules/mydownloads/singlefile.php?lid=23
私も、印象的にはこんな感じです。
XOOPSForm使ってるんですね。デザインに拘り無ければ、
一斉レンダリングで問題ないですよね。
JavaScriptでの値チェックは私もやりたいなーと常々思ってるんですが、
なかなかスマートにやる方法が思いつかず・・。
やっぱりテンプレにScript書いて書いてになるのかな。
伊藤
ITOH Takashi
時田さん、はじめまして。
> もう見てらっしゃるかもしれませんが、汎用データベースモジュール waffle と
> いうのを公開しています。
はい、存じ上げております。:)
確か、テーブルごとガンガンと増やしていく方法でしたよね。
X2の時は、Duplicatable仕様がひたすら面倒だったので、私もその方法かなーと
思ってたのですが、XOOPSCubeになって、モジュールをDuplicatable仕様にすることが
かなり簡単になった(しかも、やり方がいろいろある)ので、1つのモジュールで
テーブル1つを完全に管理する方法の方が、コード的にメンテが楽なのかな。。と思っています。
あと、テーブル構造を変えることを前提にすると、フィールド定義を自動で作ってくれる
ORMが必須かなという気がしています。SQL書くわけに行かないですよね。
で、私は結構、ALTER使ってガシガシDB構造を変えてやることに抵抗があるんですが、
みなさんはあまりないのでしょうか？
といっても、私の懸念もあまり定量的なものではなく
「データが万件単位で増えた時に、ALTERしてしまうと壊れそう」
という感覚的なものなのですが。
ただ、実際にALTERで壊れたって言うことを聞いたことも無く、
その辺はMySQLは意外と丈夫なのかなと思ってみたり。
Postgresなんかは、ALTERで増やしても削除は出来ないんですよね・・。
増やすのもケツにしか付けられないし。
(8になってできるようになったのかな？)
・・・独り言に近いな;;
伊藤
時田正彦
伊藤さんどうも。
時田です。
> はい、存じ上げております。:)
おお、ご存知とは、、ありがとうございます。
> あと、テーブル構造を変えることを前提にすると、フィールド定義を自動で作ってくれる
> ORMが必須かなという気がしています。SQL書くわけに行かないですよね。
waffle は内部的には以下のような YAML 定義を作成して、いわゆる
O/R MAP 的にデータにアクセスしています。テーブル構造が変わるとYAML定義が
変わり、それに合わせてライブラリ動作します。
なのでベタなSQLは書かないようになっています。
YAML のテーブル定義
---------------------------------------
name: waffle0_data1
desc: アジアの国
columns:
-
name: t1_id
desc: ID
type: integer
valid: 1
uniq: 1
not_null: 1
order: 0
primary_key: 1
fixed: 1
serial: 1
-
name: t1_c1
desc: 国名
type: string
not_null: 1
order: 100
detailview: 1
insertview: 1
updateview: 1
listview: 1
updatable: 1
maxlength: 255
size: 32
（...続く）
----------------------------------------
カスタマイズの依頼を受けてお仕事したりしているのですが、画面が汎用的じゃ
ないので、結局ベタなPHPプログラム作ることが多かったりします。。。
ITOH Takashi
> おお、ご存知とは、、ありがとうございます。
いえいえ、時田さんくらい色々やってるのはminahitoさんくらいかなぁと
思い記憶に残っております。:)
久しぶりにWaffle見てみました。。
もうこれでいいんじゃないでしょうか、という気になりますね。
しかし、ここはXOOPSCubeであえて作ってみたい気もします。:-p
>> あと、テーブル構造を変えることを前提にすると、フィールド定義を自動で作ってくれる
>> ORMが必須かなという気がしています。SQL書くわけに行かないですよね。
>
> waffle は内部的には以下のような YAML 定義を作成して、いわゆる
> O/R MAP 的にデータにアクセスしています。テーブル構造が変わるとYAML定義が
> 変わり、それに合わせてライブラリ動作します。
> なのでベタなSQLは書かないようになっています。
これは、一端どこかにキャッシュYAMLファイルwを作ってたりするんですか？
内部的に・・・ということなんで、毎回DBからパースしてるんでしょうか？
# 動かしてみたけど、cacheとかにその形跡はないし・・・
伊藤
gus...@gmail.com
> 久しぶりにWaffle見てみました。。
> もうこれでいいんじゃないでしょうか、という気になりますね。
うおおおお。
自分がやろうとしてたことが殆ど実装済みどころか、もっと細かいレベルで操作
ができるようになってる。
確かに、これで良いんじゃないでしょうか、と思ってしまいました^^;
> >> あと、テーブル構造を変えることを前提にすると、フィールド定義を自動
で作ってくれる
> >> ORMが必須かなという気がしています。SQL書くわけに行かないですよね。
> >
> > waffle は内部的には以下のような YAML 定義を作成して、いわゆる
> > O/R MAP 的にデータにアクセスしています。テーブル構造が変わるとYAML定
義が
> > 変わり、それに合わせてライブラリ動作します。
> > なのでベタなSQLは書かないようになっています。
やっぱり、テーブル定義の変更って必要なんですかね。。。
伊藤さんも書かれていますが、用途によってはALTER TABLEの最中に書き込みが
あったら、とか考えると定義変更は極力避けたいと思ったりするんですよね。
gus...@gmail.com
> Postgresなんかは、ALTERで増やしても削除は出来ないんですよね・・。
> 増やすのもケツにしか付けられないし。
> (8になってできるようになったのかな？)
思わず反応してしまいました（苦笑
いつ頃からかは判りませんが、今のPostgreSQLは、ALTER TABLEで列の削除なん
かも出来るみたいです。
http://www.postgresql.jp/document/pg824doc/html/ddl-alter.html
GIJOE
今朝はXUGJが妙に重いので、ひさびさにMLに投稿します。
> > 久しぶりにWaffle見てみました。。
> > もうこれでいいんじゃないでしょうか、という気になりますね。
>
> うおおおお。
> 自分がやろうとしてたことが殆ど実装済みどころか、もっと細かいレベルで操作
> ができるようになってる。
> 確かに、これで良いんじゃないでしょうか、と思ってしまいました^^;
waffleって、最初に見た時点であまりにも穴だらけだったので、私の中では、
tokitaという名前がブラックリストに入ってました。（ごめんなさい）
今はどうなんでしょうか。
そのあたりがすべて書き直されているなら検討対象になるかもしれませんね。
もっとも話を聞く限り、私の望んでいるものとは正反対のようなので、私は
私で作ると思いますが。
> やっぱり、テーブル定義の変更って必要なんですかね。。。
> 伊藤さんも書かれていますが、用途によってはALTER TABLEの最中に書き込みが
> あったら、とか考えると定義変更は極力避けたいと思ったりするんですよね。
そりゃどんなDBエンジンだって、ALTER中にロックくらいはするでしょう。
私の経験上では、少なくともMySQLでALTERをそこまで避ける必要性は感じま
せんね。最悪壊れてもインデックスくらい。
実際、onupdateあたりでは、ALTERバシバシ使ってますし。
（モジュールアップデートと汎用DBモジュールのフィールド変更とでは、頻
度も同じくらいでしょう）
MySQLの良いところは、テーブルが単純なファイルだってことです（少なくと
もMyISAMは）。バックアップ・リストアも極めて容易なのですから、そんな
に怖がる必要は感じませんね。
ただ、汎用DBを作るためにALTER TABLEっていうのはアイデアとしてあまりに
も安易かなあ、という一点で、私もALTER否定派です。
GIJOE
どこにレスつけるのが適当かなやんだのですが、とりあえずここに。
> > ・カテゴリは考え方によると思いますが、既存の物にあるようなデータが必ず「ひとつのカテゴリ」に所属するタイプではなく、複数のカテゴリに所属できる
> > こと。そのためカテゴリの階層構造は諦めてます。
>
> fabiさんの挙げた条件では、カテゴリの複数所持が一番大変そうですね。
> むしろ階層構造のほうが簡単です。
多対多モデルでも多対一モデルでも、常にリンクテーブル(?)を作るようにす
れば、処理としては同じですよね。（単に多対一の場合に、オーバースペック
でやや重くなる）
多対多だからといって、階層構造を諦める必要はありませんが、その場合、
アイテムからカテゴリーを遡るルートが一意にならないのが問題になります。
判りやすい例としてはパンくずでしょうか。
http://cube.undo.jp/modules/mpdb/index.php/detail.html
のパンくずは、「弁護士」でしょうか。それとも「その他」でしょうか。
ヤフオクみたいに、シンボリックリンクみたいにしてしまう、というのも手
ですが…
あと、fabiさんが例示したカテゴリーって、どちらかというとタグですよね。
もちろんタグも多対多カテゴリーの一つにすぎないのですが、それはそれで、
別の構造として用意した方が、利用者としてはより直感的になると思います。
> で、入力フォームを作る際ですが、デザイナーにプレースホルダを提示するか、
> 自動でくみ上げちゃうのかっていう感じかと思います。
>
> 前者の場合、
> <{form_input name="item_name" size="***"}>
> っていうのが「ある項目」の入力フォームになる。デザイナーはこれ使って
> ぺたぺたとテンプレを作っていく感じです。
>
> 後者の場合、かのXOOPSFORMのように、フォームがワンセット。
> <{$form_table}>
> みたいなひとつの変数にレンダリングされてしまう感じです。
私はどちらも嫌ですね。特に後者は論外でしょう。
フォームをデザイナーに好きに作ってもらって、HTML Validation。
HTML解析して得られたフィールド群がテーブルの構造になります。もちろん、
その都度HTML解析してらんないので、キャッシュはうまく作る必要がありま
す。
> で、ALTER TABLEを使わない(項目数きめ打ち)方法だと、ひとつのフィール
> ドにシリアライズして全部つめちゃうとか。これだと検索とか出来ないで
> すね。
そんなことはないですね。文字列検索なら、それこそ、文字列検索用のフィ
ールドを１個用意して、適当なセパレータで検索対象とするフィールドの値
をCONCATして格納しちゃえばいいんです。
数値検索だとそういう訳にはいかないので、その場合はALTER TABLE必須でしょ
う。
同様に、ORDER句の対象とする場合もDBにフィールドを追加するしかないかな
あ、という感じです。
データ更新時に、冗長情報として、アイテムのランキングを保存しておく、
なんていうものすごい技も思いついたのですが、さすがに件数が多くなると、
SQL文長がものすごいことになりそうですね（笑）。
カテゴリーやタグについては、ALTER TABLEというより、CREATE TABLEと
DROP TABLEの組み合わせでしょうかね。カテゴリーテーブルそのものと、リ
ンクテーブルを２つセットで作る。これについては、他の解法はないかな、
という気がしています。
GIJOE
メールを遡って読んでいるので、レスの順番が逆転してしまってすみません。
> ではDevelopers Group なら話を聞いてもらえるだろうということでここに
> 投げます。
私は良い企画だと思います。少なくとも画面を作っている時点でクレクレじゃ
ないですよ。
nobunobuさんの開設意図も、まさにこういうのをやろうってことでしょうし。
tohokuaikiさんも書いてましたが、テンプレートが先に形として見えているっ
ていうのはいいですよね。
モジュール開発する上で一番しんどいのは、HTMLを0から書くことですし。
（少なくとも私はそうです）
しかし、このモジュールトップの構成要素って、XWordsそっくりですね。
カテゴリーで抽出条件が「ABCD...」となるだけ。
もしかして、XWordsなんかも、この汎用DBのサブセットで済んでしまう？
fabi
> しかし、このモジュールトップの構成要素って、XWordsそっくりですね。
> カテゴリーで抽出条件が「ABCD...」となるだけ。
>
> もしかして、XWordsなんかも、この汎用DBのサブセットで済んでしまう？
最初に書いたように、以前作った人材派遣の求人サイトのテンプレートが下敷きなんですけどね。（笑
管理画面ではちょっと参考にしたりはしました。
辞典もデータベースの一形態なので、テンプレートをいじればああいったカード型DBは容易に作成できるはずです。
あとは人名録や、映画データベースや、リンク集、ショップなどのデータベース。
もちろん求人情報など業務用にも使えることを想定してますが、どちらかというと趣味の分野に使ってもらえる方が嬉しかったりしますね。
のぶのぶ
07/11/21 に GIJOE<g...@peak.ne.jp> さんは書きました:
> > ではDevelopers Group なら話を聞いてもらえるだろうということでここに
> > 投げます。
>
> 私は良い企画だと思います。少なくとも画面を作っている時点でクレクレじゃ
> ないですよ。
>
> nobunobuさんの開設意図も、まさにこういうのをやろうってことでしょうし。
はい！「まさに」です。
（小生が日本を離れていてネットにでれない間にこんなトピックがあがっていたなんて・・・）
「汎用DB」の「汎用」にどこまで求めるかは、人それぞれだとおもいますが、
これさえあれば、他のモジュールいらない（笑）ってな優れものができないかなぁ・・・
冗談はともかくとして、「項目」の考え方については、別途のレスを書かせてもらおうと
おもってます。
（ その前にとりあえず「waffle」を評価しないとと考えているのですが・・・＾＾； ）
----------------
Nobuki Kowa
Nob...@Kowa.ORG
----------------
時田正彦
時田です。
> いえいえ、時田さんくらい色々やってるのはminahitoさんくらいかなぁと
> 思い記憶に残っております。:)
いえとんでんもないです。
> これは、一端どこかにキャッシュYAMLファイルwを作ってたりするんですか？
> 内部的に・・・ということなんで、毎回DBからパースしてるんでしょうか？
> # 動かしてみたけど、cacheとかにその形跡はないし・・・
waffle0_config テーブルにデータテーブルのYAMLとキャッシュデータが入って
います。
また modules/waffle0/yaml/ 以下に waffle 自体のテーブルを操作する
YAMLファイルが入っています。
モジュール内で ALTER TABLE を使うのは、やっぱり自分も最初抵抗がありまし
た。それでも使ったのは、以前仕事で積極的に ALTER を使うシステムを担当し
ていてとくに問題なく安定して運用できたいたのと、素直にカラムを追加した方
が MySQL のパフォーマンスが出ると（そのときは）思ったからでした。
他によい方法が思いつかなかったというのもありますがー。
fabi
ALTERを使って項目を可変にするかどうかを検討してもらっているのですが、やはりフィールドは固定して持っていた方がシンプルではないでしょうか。
項目数が少ないというのであれば最初から空の項目（フィールド）をその分持っていればいいんじゃないかと思います。
項目追加をするということは、先ずテキスト項目か選択項目かを選び、テキスト項目の場合はシングルラインかマルチラインを決め、マルチラインの場合は行
数の設定も必要です。
選択項目の場合はもっと複雑で、プルダウンメニューかチェックボックスかラジオボタンかを決めて、さらにその項目の入力方法（これが決定版のやり方が無
く、しかもどうしても複雑になってしまいます）も検討せねばなりません。
昨日、別スレッドにも書きますが、カテゴリ別けの考え方を変えました。GIJOEさん仰るように私のカテゴリの考え方は「タグ」ですが、これをいくつか
のグループに別けて管理する考え方にしました。
これにより「複数の選択肢からひとつ、または複数を選ぶ」という項目はこれに内包されてしまいます。よって追加項目はシングルまたはマルチのテキスト
ボックスだけ考えればいいとしました。
ただしフィールドを固定するということが検索機能に支障が出るのであれば考え直します。
とりあえず新案の項目管理ページのサンプルをこうしてみました。
http://cube.undo.jp/modules/mpdb/index.php/admn_item_edit.html
tohokuaikiさん案の項目追加も捨てがたいので別案としても作ってみました。
http://cube.undo.jp/modules/mpdb/index.php/admn_item_edit_alt.html
選択項目の追加方法はADDBOOKのまんまパクリです。
fabi
http://cube.undo.jp/modules/mpdb/index.php/main.html
GIJOEさんの仰るように今回カテゴリ＝タグであるということを否定しません。
というか積極的にその方向にしたいと考えています。
各データを何かのグループに所属させて分けてしまう考え方もありますが、データを階層化せずにその所属を各データ側でタグとして持ったほうが融通が利く
と考えています。結局のところ検索時の選択肢として抽出できれば良い訳ですから。
例えば俳優データベースを作ると仮定します。
俳優データベース━┳━男優 ━┳━映画俳優
┃ ┣━TV俳優
┃ ┣━舞台俳優
┃ ┗━声優
┗━女優 ━┳━映画俳優
┣━TV俳優
┣━舞台俳優
┗━声優
というカテゴリ分けがあるとすれば、人によっては映画にもテレビにも舞台にも出ている役者さんはいる訳ですね。であれば、フラットにした選択肢から必要
な項目を選んでもらって注出した方が合理的と考えるわけです。
例えば男優、映画俳優、舞台俳優にチェックを入れてもらって検索すれば、そのいずれかに引っかかる役者さんが抽出されるわけです。映画と舞台両方に出演
している役者だけを抽出するには、キーワードで「映画」かつ「舞台」とすればいい。
よって階層化されたカテゴリは必要ないと考える訳です。
とここまで考えて、色んなデータベースのパターンを検討してみると、どうも不動産データベースの場合都合が悪いことに気づきました。
不動産データベース━┳━新築 ━┳━一戸建て━┳━路線別・・・
┃ ┃ ┣━間取り別・・・
┃ ┃ ┗━価格別・・・
┃ ┗━マンション━┳━路線別・・・
┃ ┣━間取り別・・・
┃ ┗━価格別・・・
┃
┗━中古━┳━一戸建て━┳━路線別・・・
┃ ┣━間取り別・・・
┃ ┗━価格別・・・
┗━マンション━┳━路線別・・・
┣━間取り別・・・
┗━価格別・・・
という階層構造を持つ訳ですが、これをそのまんまフラットにしてみると選択肢として訳が判らなくなってしまうのです。
路線名と価格を同列に取り扱うことは出来ません。かといってひとつの物件が複数の路線に所属するということや、マンションなど複数の間取りにまたがると
いったことは十分ありえる訳ですよね。
それで「カテゴリのグループ化」という観念を持ち込むことにしました。
カテゴリは相変わらずフラットですが、五つまでのグループを作ることが出来ます。そして検索表示ではこれらを段落として分けて表示できます。
これでかなりのＤＢパターンをフォローできると考えるのですが。
検索時のカテゴリ表示
http://cube.undo.jp/modules/mpdb/index.php/main.html
詳細だと各グループ毎に改行されてこんな感じに表示（リスト表示も同様）
http://cube.undo.jp/modules/mpdb/index.php/detail.html
管理画面ではこんな感じでカテゴリの追加と名称変更を行う
http://cube.undo.jp/modules/mpdb/index.php/admn_category_edit.html
どうでしょうね。
fabi
先ず、私はソースの良し悪しは判りませんから、主に機能面での検証を行っています。
waffleは自由度としてはほぼ満点に近いんじゃないかと思います。「カテゴリ」の観念を持たないのは私と同じです。
しかし、これはその自由度ゆえにか、構築前にちゃんと設計をしないといけないんですよね。その操作も煩雑で、ある程度の知識が必要です。
家計簿を自分で作るときにエクセルのまっさらなシートを前に途方にくれる感覚に近いです。
対してADDBOOKは、ある程度サンプルとしてのデータが入っていることもあってか、直感的に出来上がりが頭の中で想像できます。私としてはこちらの
方の路線を継承して、比較的簡単に誰でもデータベースサイトを構築できるということを目標にしています。
例えばフィールド追加に制限を設けて、項目の変更を容易にするとかですね。現在の私のテンプレートだと、ほぼ何の設定もせずに、カテゴリ追加だけで人名
データベースやリンク集として使えるでしょう。
「汎用」の考え方ですが、色んなパターンのリスティングに使えれば「汎用」ですからそれほど考え込まなくてもいいんじゃないかと思います。少なくともこ
こに上げたモジュールはどちらも「汎用」ですし。
mylinksやweblinksは同様なパターンのデータベースですが、リンクモジュールとして特にチューニングされている訳ですから、「転用」は出
来ますが「汎用」ではありません。
のぶのぶ
コンテンツの意味論からのアプローチだと、「カテゴリー」とか「タグ」というのは、
各レコードを分類し、絞込み検索を行って、容易に目的のコンテンツにたどり着く
為に必要なものだと理解していますが。
データベース側からのアプローチからだと、単に
「マスター」データに関係を持つ一項目に過ぎないとです。
上記不動産の場合だと
「新古区分」
「住居携帯」 一戸建て・マンション
「間取り」 ワンルーム・１K・・・・・・・
「地域」 山手線 沿線
「価格帯」 1000千万以下・・・・・
という5つの項目があって、それぞれの項目に値を示すマスターデータが存在する
というだけだとおもいます。
fabiさんの要望の固定数項目でなく本当に、可変汎用にするのであれば、
項目定義時に、項目毎に検索絞込みが可能か、その優先順位は？などを定義し、
その定義内容によって、画面遷移を組み立てるという形の方が、
データベースからのアプローチとしてはまともだと考えます。
この意味で、別途GIJOEさんが、カテゴリーは、
Create Table Drop Tableが必要と書かれていたのだと思いますが、
名称だけが必要だったりする分には、別に新しいテーブルでなく、
汎用の名称引き専用マスタを用意しておくだけでも良いかもしれません。
もちろん、今までの議論の中にも出てきているように 項目によって、
マスタとの関係が「１：ｎ」（単一選択）か「ｎ：ｎ］(複数選択化）とか
マスタ内データの階層化をどのようにするかとかも考えないと
いけないですが、こちらは、マスターの扱いをうまくカプセル化してやれば
マスターの定義やリンクテーブルの定義側の変更だけで
済ますことも出来なくは無いと思います。
まぁ、ここまで重装備にするかどうかは別ですが、ご参考まで。
07/11/22 に fabi<mino...@gmail.com> さんは書きました:
ITOH Takashi
> waffleは自由度としてはほぼ満点に近いんじゃないかと思います。「カテゴリ」の観念を持たないのは私と同じです。
> しかし、これはその自由度ゆえにか、構築前にちゃんと設計をしないといけないんですよね。その操作も煩雑で、ある程度の知識が必要です。
> 家計簿を自分で作るときにエクセルのまっさらなシートを前に途方にくれる感覚に近いです。
>
> 対してADDBOOKは、ある程度サンプルとしてのデータが入っていることもあってか、直感的に出来上がりが頭の中で想像できます。私としてはこちらの
> 方の路線を継承して、比較的簡単に誰でもデータベースサイトを構築できるということを目標にしています。
Waffleはサンプルもありますよ。
サンプルを生成してしまうとそれまで作ったデータテーブルはなくなってしまいますが、
これの考え方は便利だと思いました。
つまり、プリセットを用意しておいて、必要ならそれをLoadするという。
Duplicateに作っておけば別にモジュールインストールして
サンプルをロードすれば良いですからね。(WaffleもD2)
伊藤
ITOH Takashi
>> これは、一端どこかにキャッシュYAMLファイルwを作ってたりするんですか？
>> 内部的に・・・ということなんで、毎回DBからパースしてるんでしょうか？
>> # 動かしてみたけど、cacheとかにその形跡はないし・・・
>
> waffle0_config テーブルにデータテーブルのYAMLとキャッシュデータが入って
> います。
おぉ！そんなところに。。
> モジュール内で ALTER TABLE を使うのは、やっぱり自分も最初抵抗がありまし
> た。それでも使ったのは、以前仕事で積極的に ALTER を使うシステムを担当し
> ていてとくに問題なく安定して運用できたいたのと、素直にカラムを追加した方
> が MySQL のパフォーマンスが出ると（そのときは）思ったからでした。
> 他によい方法が思いつかなかったというのもありますがー。
うーむ、こんな感じでしょうか。
ALTER抵抗ある派
┃
┣テーブルが壊れちゃうんじゃないか(伊藤)
┃ ┃
┃ ┣━やってみたら意外と平気(時田)
┃ ┃
┃ ┗━MySQLのロックなんて信じないよう(gusagi)
┃
┗━そもそもALTERなんて安直過ぎて面白くないよ(GIJOE)
私、以前にADDBOOKでALTER使わずにやってみたんですが、もうやりたくないってのが
本音です。頭がこんがらがりました。
伊藤
のぶのぶ
一言レスですが・・・・
小生は、「別にALTER TABLE使っても良いんで無いの？」派です。
但し、原則として、（GIJOEさんが書かれていたのとほほ同じですが）
・項目の定義変更の機会はそれほど無い
・モジュールのアップデートと同様で、DBMSに信頼が置けないなら、
サイトの重要度によっては、深夜にサイトクローズしてやれば良い
・もっと慎重にやるなら、事前にバックアップとって置けば良い
っていう運用を前提とするということです。
なので、究極のユーザビリティーを求めるなら、モジュール管理側で
バックアップ・リストア機能あると安心度は高まるかと。
どうせ、項目増やす場合には、デザイン重視サイトならテンプレートも
変更するでしょうし、あんまりオンライン状態のままで定義変更なんて
シーンは思い浮かばないのですが・・・
別の設計として、あまり検索頻度が高くないような属性項目は、
別途下記項目を持つ属性専用テーブルを用意するってのもありだとは思います。
「主テーブルのレコードID」
「項目名」
「項目値(数値）」
「項目値(文字列)」 ・・・項目タイプによってフィールドを分けるかどうかは要検討
この場合でも、項目定義に変更があった場合には、何らかの形で、このテーブルの
データ一括処理が必要になるわけですから・・・
結局運用負荷は、あんまり変わらないのではと思いますが・・・
GIJOE
ALTERを使うかどうかとは別次元の問題で、こういう項目管理は私の好みじゃ
ないですね。
まるっきり、Liaiseとか白扇と同レベルじゃないですか。
こういうのって、結構細かい手間がかかる割に、フォーム作成の自由度を奪
うだけの設計なので、作ってて面白くなるとは思えません。（私にとって
XOOPSはあくまで趣味なので、面白いかどうかがモチベーションと直結します）
フォーム設計（フィールド定義）をブラウザでやるっていうのもストレスが
たまるだけという気がします。それだったらXMLで定義を書いてCubson使う方
が、はるかに「汎用DB」という意味に近い気がしますね。
それをやったら、XCL専用になってしまうのでやりませんけど。
昔と比べて今では、大量データの処理能力が格段に上がっています。
だから、テーブルのカラムそのものは増減しないけど、固定数の冗長カラム
に巨大なデータを突っ込んでうまく処理する、なんて方法なら作っていて楽
しいかな、なんて考えてます。
GIJOE
> 家計簿を自分で作るときにエクセルのまっさらなシートを前に途方にくれ
> る感覚に近いです。
だから、まさにエクセルシートを添付すればいいんですよ。
フィールド定義とか初期値設定を、ブラウザでやるなんてナンセンスです。
１テーブルを処理するなら、表計算アプリケーション以上のツールはありま
せん。
そのシートをアップロードしてもらう。
それがそのままフィールド定義にもなるし、初期値にもなる。
ダウンロードもxlsにすれば、ダウンしてデータ書き換えてアップロードとい
う流れも、CSVよりスムーズです。（CSVだとカラム幅とか表示形式情報がな
いのが痛い）
…という設計で、Excelのxlsファイル（ただしXML形式）をやりとりするイン
ターフェースを途中まで作ったことはあります。（１～２年前）
どうして挫折したかというと、Excelに貼り付けた画像を取り出す方法が見つ
からなくて嫌になったという…
画像もフィールドに貼り付けたものをそのまま反映させたいじゃないですか。
でも、XML形式だと画像を含められないし、バイナリ形式だと解析が死ぬほど
面倒……orz
GIJOE
突っ込もうと思ってたら、のぶのぶさんに先を越されてました。
しかも、fabiさんのサンプルサイトのカテゴリー管理画面さえもすでに書き
換わってます（笑）
不動産情報だと、15～6個はマスタがありますね。
そして、多対多も多対一もありますし、階層構造があるものもあります。
多対一の階層構造例：住所
東京都-千代田区-一番町１丁目
多対多の階層構造例：最寄り駅
半蔵門線-半蔵門駅
有楽町線-麹町駅
いろいろな意味で、相当にハードルが高いでしょうが、これをすべて実装で
きたなら、ほとんどのカテゴリー構造を再現できると言えるでしょう。
リレーションの正規化なんてのを今さら論じるつもりはありませんが、やっ
ぱりそういうルールをある程度守った方が最終的に使いやすいのは確かだと
思います。
あと、価格帯なんてのは逆にカテゴリーになりませんよね。
価格の従属条件に過ぎませんから。
> 名称だけが必要だったりする分には、別に新しいテーブルでなく、
> 汎用の名称引き専用マスタを用意しておくだけでも良いかもしれません。
これが私のイメージするタグですね。
タグなんかはそれこそ固定で１つ持っておいても良いかもしれません。
タグを２種類以上設定する状況ってありますか？
のぶのぶ
「汎用」とは少し離れますが・・・
最近、ある新サイト公開用にモジュールを書いているのですが、
この開発に、D3に対応した拙作のモジュール開発労力低減用のフレームワークを使用しています。
このフレームワークはNBFrameと銘打って、すでにMyGmapのV2に使用しており、
リポジトリ及びスナップショット公開をしているのですが・・・
このスレッドを見ていて、モジュール単位でテーブルレイアウトのカストマイズができるような
仕組みをこのフレームワークに組み込んでみました。
モジュールインストールとモジュールアップデートとで別々のSQLやバージョンの判定ロジックを
組み込むのが面倒なため、SQLを組み込むための定義をPHPで書いてやり、これを読み込むこと
によって、モジュールインストール時のテーブル生成、モジュールアップデート時のALTER文生成も
自動で行い、別途XOOPSFormベースのカストマイズ可能な自動フォーム生成と組み合わせると、
XOOPS_TRUST_PATH下の定義に対してXOOPS_ROOT_PATHのモジュールディレクトリ下に
項目追加を行った独自のテーブル定義をおいてやれば、管理画面でのメンテに関しては、
自動的に追加した項目を反映できるなんて事ができるようになりました。
他のテーブルとの関係定義は無いため、マスタ参照項目の追加を無修正でって訳にはいきませんが・・
これで、D3モジュールの、テーブル定義、テンプレート定義、言語定数定義すべてモジュール固有の
定義オーバーライドが可能になるので、モジュールに対してかなりの自由度付与ができると思います。
（これらの定義の一部はALTSYS併用によってさらに便利になります）
現在作成中のモジュールに関しては、ある事情によってソース公開することはできませんが、
NBFrameの拡張版及びそれをベースとしたサンプルソースやこれを反映したMyGmapV2は、
近々オープンにする予定です。
但し、かなりオーバーヘッドがあり、重い事は確かですが、最近のホスティングサーバでは、
それなりのレスポンスにて稼働しています。
とりあえず、ご参考まで・・（って参考にできる具体物が無いって、GIJOEさんにつっこまれそうですが）
---------
のぶのぶ
---------
時田正彦
どうも、時田です。
> waffleって、最初に見た時点であまりにも穴だらけだったので、私の中では、
> tokitaという名前がブラックリストに入ってました。（ごめんなさい）
> 今はどうなんでしょうか。
> そのあたりがすべて書き直されているなら検討対象になるかもしれませんね。
あの時は失礼しました。
今思い出したのですが、サニタイズ関係はこれを参考にしてまして、漏れはない
と思います。
http://tokita.net/modules/pukiwiki/31.html#ct31_1_8
で、もともとGIJOEさんが書いていた文章だったなーと、それが書きたかっただ
けだったり。とても参考にさせてもらいました。
GIJOE
> モジュールインストールとモジュールアップデートとで別々のSQLやバージョ
> ンの判定ロジックを組み込むのが面倒なため、SQLを組み込むための定義を
> PHPで書いてやり、これを読み込むことによって、モジュールインストール
> 時のテーブル生成、モジュールアップデート時のALTER文生成も自動で行い、
> 別途XOOPSFormベースのカストマイズ可能な自動フォーム生成と組み合わせ
> ると、XOOPS_TRUST_PATH下の定義に対してXOOPS_ROOT_PATHのモジュールデ
> ィレクトリ下に項目追加を行った独自のテーブル定義をおいてやれば、管
> 理画面でのメンテに関しては、自動的に追加した項目を反映できるなんて
> 事ができるようになりました。
これって、リクエスト毎にそういう処理を行うのでしょうか？
であれば確かに重くなりそうな気はしますが、XCL2.1も十分に重量級なので、
気にするレベルじゃないかもかもしれません。
私が考えているのは、Smartyのコード版っていうんでしょうか。
PHPフレームワーク的に書いたものを、PHPベタコードにコンパイルして、コ
ンパイルキャッシュを作成し、リクエスト毎には、そのコンパイルキャッシュ
を実行するというタイプです。
XCLに対してアクセラレータなどを使うと妙に速くなりますが、アクセラレー
タの効果が一番大きいのはクラス解析のようです。（自分で実験した限り）
かといって、アクセラレータは副作用が消せない。
だから、フレームワークものをベタコードに展開すれば、相当に速くなるん
じゃないかな、なんて考えてます。アクセラレータと違うのは、おかしな動
作があっても、ベタコードを追いかければとりあえず自分でデバッグができ
る、という一点。
開発はフレームワーク、実行はベタコード、といういいとこ取りで :-)
……でも、これって、Cコンパイラを作るのと同じ労力がかかる？
> これで、D3モジュールの、テーブル定義、テンプレート定義、言語定数定
> 義すべてモジュール固有の定義オーバーライドが可能になるので、モジュ
> ールに対してかなりの自由度付与ができると思います。
> （これらの定義の一部はALTSYS併用によってさらに便利になります）
このあたりは実装を見るのが楽しみですね！
# 旧NBFrame、読まなきゃと積んであります（汗
# 新NBFrameこそは読むぞ！
GIJOE
時田さん、こんにちは。
> あの時は失礼しました。
いえいえ。こちらこそ失礼しました。
腕も伴ってないくせに、口の悪さだけはJM2師匠ゆずりで（笑）
> 今思い出したのですが、サニタイズ関係はこれを参考にしてまして、漏れはない
> と思います。
> http://tokita.net/modules/pukiwiki/31.html#ct31_1_8
> で、もともとGIJOEさんが書いていた文章だったなー
私、こんな文章をどこかで書きました？
私自身は、
・リクエスト
・生データ
・エスケープ済(DB用,HTML用)
という3(4)種類のステータスを常に意識するように、ということを繰り返し書
いてきているはずです。
例えば、文字列型として記述してある
POSTデータの<textarea>内表示：stripSlashesGPC(htmlSpecialChars($text))
なんてあり得ないですよね。
今どきmagic_quotes_gpc=on設定のサイトがどれくらいあるかしりませんが、
その影響を消したものを生データとして受取り、かつ、編集画面用にエスケ
ープするなら、
htmlspecialchars($myts->stripSlashesGPC($text),ENT_QUOTES)
でしょう。（$textはリクエスト）
$myts->htmlSpecialchars() は、& の処理がおかしいのであえて使いません。
あと、生データをDB用にエスケープする場合、本当にaddslashes()で良いの
かどうかについては議論があります。（これについて書き出すと長くなるの
でやめておきますが）
のぶのぶ
> > モジュールインストールとモジュールアップデートとで別々のSQLやバージョ
> > ンの判定ロジックを組み込むのが面倒なため、SQLを組み込むための定義を
> > PHPで書いてやり、これを読み込むことによって、モジュールインストール
> > 時のテーブル生成、モジュールアップデート時のALTER文生成も自動で行い、
> > 別途XOOPSFormベースのカストマイズ可能な自動フォーム生成と組み合わせ
> > ると、XOOPS_TRUST_PATH下の定義に対してXOOPS_ROOT_PATHのモジュールデ
> > ィレクトリ下に項目追加を行った独自のテーブル定義をおいてやれば、管
> > 理画面でのメンテに関しては、自動的に追加した項目を反映できるなんて
> > 事ができるようになりました。
>
> これって、リクエスト毎にそういう処理を行うのでしょうか？
> であれば確かに重くなりそうな気はしますが、XCL2.1も十分に重量級なので、
> 気にするレベルじゃないかもかもしれません。
いや、あくまでもモジュールインストトール及びモジュールアップデート時の動作です。
従来のNBFrameでは、X2なりXCLのインストーラの使える機能は極力使って、
インストラーのカスタム部分でD3対応のrenameをかけたりしていましたが、
この方がかえって動きが複雑になってしまったので今回の修正で、
テーブル生成・テンプレート生成はGIJOE版D3と同様すべてNBFrame内で
自前生成を行うように変更し、この中でテーブル生成はSQLでない定義ファイルにして
モジュールアップデート時にもこれを参照するって方式にしたと言うことです。
> 私が考えているのは、Smartyのコード版っていうんでしょうか。
> PHPフレームワーク的cに書いたものを、PHPベタコードにコンパイルして、コ
> ンパイルキャッシュを作成し、リクエスト毎には、そのコンパイルキャッシュ
> を実行するというタイプです。
cubesonでベタコードをはき出すようにするってのもありかもしれませんね＾＾；
> > これで、D3モジュールの、テーブル定義、テンプレート定義、言語定数定
> > 義すべてモジュール固有の定義オーバーライドが可能になるので、モジュ
> > ールに対してかなりの自由度付与ができると思います。
> > （これらの定義の一部はALTSYS併用によってさらに便利になります）
>
> このあたりは実装を見るのが楽しみですね！
（本来別スレにすべきですが・・・）
ALTSYSの言語定数定義、かなり便利なのですが、小生にとってはいくつか問題点があります。
（といいつつ、クレクレモードになっていますが・・・）
・D3対応モジュールの場合にXOOPS_ROOT_PATH側でオーバーライドした言語ファイルを
見に行ってくれない。
確かにこの画面でカスタマイズできる以上は、モジュール毎のオーバーライドは必要ない
という考え方ができますが、定数を追加したいという場合にはやはりオーバーライドの
必要があります。
（オーバーライドできなくても、定数追加機能が管理画面にあったら良いのかもしれませんが）
・main.php admin.phpについて$constprefを使用してモジュール名に従って定数名を
書き換える方式での定義を行うと、モジュール内の管理画面にALTSYSを組み込んだ
場合にうまく読み込めない。modｈinfo.phpだけ対応するロジックになっている。
通常のモジュールだとmain.php admin.phpに定義された定数をモジュールの
ロジック内で固定で使用することが多いのでこのような使用をすることがまれだと
思いますが、NBFrameでは、定数直使用を行わない方式をとっているので、
dirname単位での言語管理を可能にしています。
ってなところが何とかなれば、相性ばっちりなんですが・・・
---------
のぶのぶ
---------
GIJOE
すっかり化石レスにて恐縮ですが…
> いや、あくまでもモジュールインストトール及びモジュールアップデート時の動作です。
> 従来のNBFrameでは、X2なりXCLのインストーラの使える機能は極力使って、
> インストラーのカスタム部分でD3対応のrenameをかけたりしていましたが、
> この方がかえって動きが複雑になってしまったので今回の修正で、
> テーブル生成・テンプレート生成はGIJOE版D3と同様すべてNBFrame内で
> 自前生成を行うように変更し、この中でテーブル生成はSQLでない定義ファイルにして
> モジュールアップデート時にもこれを参照するって方式にしたと言うことです。
なるほど、了解です。インストーラおよびアップデータであれば、タイムア
ウトさえしなければ、どんなに重くても構わないですね（笑）
> > 私が考えているのは、Smartyのコード版っていうんでしょうか。
> > PHPフレームワーク的cに書いたものを、PHPベタコードにコンパイルして、コ
> > ンパイルキャッシュを作成し、リクエスト毎には、そのコンパイルキャッシュ
> > を実行するというタイプです。
> cubesonでベタコードをはき出すようにするってのもありかもしれませんね＾＾；
私もそれを考えたのですが、Cubsonってその設計ポリシーから、自動生成さ
れたコードにさらに手を入れるのが大前提ですよね。
そうだとすると、吐き出した後のメンテをベタコードでやることになるので、
メンテナンス性と速度の両立にはならない気がします。
以下、altsysの件。
ずっと気に病んでいたのですが、ようやく手を入れる時間がとれました。
> ALTSYSの言語定数定義、かなり便利なのですが、小生にとってはいくつか問題点があります。
> （といいつつ、クレクレモードになっていますが・・・）
>
> ・D3対応モジュールの場合にXOOPS_ROOT_PATH側でオーバーライドした言語ファイルを
> 見に行ってくれない。
あれ？
D3LangMan自体は、見に行くようになってますが。
優先順位としてはこうなってます。
1. DBとマージしたキャッシュ
2. ROOT下言語ファイル
3. TRUST下言語ファイル
4. TRUST下englishファイル
それとも、言語定数管理画面(mylangadmin)において、ROOT側でオーバーライ
ドした値も表示して欲しい、という意味でしょうか。
> 確かにこの画面でカスタマイズできる以上は、モジュール毎のオーバーラ
> イドは必要ないという考え方ができますが、定数を追加したいという場合
> にはやはりオーバーライドの必要があります。
> （オーバーライドできなくても、定数追加機能が管理画面にあったら良
> いのかもしれませんが）
これについては、差分オーバーライドが良いかな、というのが私の中での結
論です。
minahitoさんのOverrideLanguageをマージしただけではありますが、こうやっ
て、差分だけ先に読み込んでしまって、後はNoticeを無視する、というのも
十分に手としてアリかな、と考えを改めました。
事実、管理は相当に楽です。もちろん、定数の「追加」もできます。
altsys-0.56a で、差分として追加した定数も確認出来るようにしておきまし
た。
> ・main.php admin.phpについて$constprefを使用してモジュール名に従って定数名を
> 書き換える方式での定義を行うと、モジュール内の管理画面にALTSYSを組み込んだ
> 場合にうまく読み込めない。modｈinfo.phpだけ対応するロジックになっている。
>
> 通常のモジュールだとmain.php admin.phpに定義された定数をモジュールの
> ロジック内で固定で使用することが多いのでこのような使用をすることがまれだと
> 思いますが、NBFrameでは、定数直使用を行わない方式をとっているので、
> dirname単位での言語管理を可能にしています。
なるほど了解です。
確かに、modinfo.php だけを特別扱いする理由はないですね。
というわけで、altsys-0.56a で改善してみました。
実のところ、その判定部分をコメントアウトしただけですが、これでうまく
動けば何よりです。
のぶのぶ
さらに、化石も風化してしまいそうですが・・・・
> > いや、あくまでもモジュールインストトール及びモジュールアップデート時の動作です。
> > 従来のNBFrameでは、X2なりXCLのインストーラの使える機能は極力使って、
> > インストラーのカスタム部分でD3対応のrenameをかけたりしていましたが、
> > この方がかえって動きが複雑になってしまったので今回の修正で、
> > テーブル生成・テンプレート生成はGIJOE版D3と同様すべてNBFrame内で
> > 自前生成を行うように変更し、この中でテーブル生成はSQLでない定義ファイルにして
> > モジュールアップデート時にもこれを参照するって方式にしたと言うことです。
>
> なるほど、了解です。インストーラおよびアップデータであれば、タイムア
> ウトさえしなければ、どんなに重くても構わないですね（笑）
これ、現在は少々修正して、別途のinifile等追加すれば、開発時に便利なように毎回アップデートする、
モードも追加してあります。
> > > 私が考えているのは、Smartyのコード版っていうんでしょうか。
> > > PHPフレームワーク的cに書いたものを、PHPベタコードにコンパイルして、コ
> > > ンパイルキャッシュを作成し、リクエスト毎には、そのコンパイルキャッシュ
> > > を実行するというタイプです。
> > cubesonでベタコードをはき出すようにするってのもありかもしれませんね＾＾；
>
> 私もそれを考えたのですが、Cubsonってその設計ポリシーから、自動生成さ
> れたコードにさらに手を入れるのが大前提ですよね。
>
> そうだとすると、吐き出した後のメンテをベタコードでやることになるので、
> メンテナンス性と速度の両立にはならない気がします。
なんですよね、小生もCubsonでの開発が試行錯誤の後戻りがしにくいので、
NBFrameでは、実行時での自動化を進めているって面があります。
あと、今のところはモジュール内のロジックで汎用化できる部分は極力NBFrame側に、
取り入れて、Own Codingを減らす事を目指しています。
> minahitoさんのOverrideLanguageをマージしただけではありますが、こうやっ
> て、差分だけ先に読み込んでしまって、後はNoticeを無視する、というのも
> 十分に手としてアリかな、と考えを改めました。
>
> 事実、管理は相当に楽です。もちろん、定数の「追加」もできます。
>
> altsys-0.56a で、差分として追加した定数も確認出来るようにしておきまし
> た。
>
my_languageでの差分定義対応便利ですね！
早速、NBFrame側でもALTSYSが無い環境でもmy_languageを参照するようににしました。
> なるほど了解です。
> 確かに、modinfo.php だけを特別扱いする理由はないですね。
> というわけで、altsys-0.56a で改善してみました。
> 実のところ、その判定部分をコメントアウトしただけですが、これでうまく
> 動けば何よりです。
0.56a先ほど稼働確認しました。
対応ありがとうございます。
なお、NBFrame自体は現在のところは、sf.netのsubversionリポジトリ
http://nobunobuxoops.svn.sourceforge.net/svnroot/nobunobuxoops/NBFrame/branches/V1_5/
にてメンテ中です。まだnotificationやcommentに対応しないのですが。
/libs/NBFrame/examples/ 下に2個ほどサンプルモジュールを添付した形にしてあります。
昨年末に公開したサイトの
http://handaidanseiob.nawok.com/modules/concert/
で使用している音楽ストリーム配信モジュールも、このNBFrameで開発しています。
このモジュールに関しては、使用しているFlashが非商用使用のみ無償利用化というものという
こともあって、いまのところソース公開予定はありませんが・・・
（Flashファイルだけ除外して配布するっていう手もありますが・・）
ポップアップウィンドウ用とか、X２でいうnocommonプログラムとかをあまり区別することなく、
それぞれを、Action Classsとして実装できるようにしているので、かなり開発を楽にすることができました。