汎用DB、現在開発中なので、そのうち公開できるかと思います。
ただ、fabiさんが出されたアイデア・画面とは全く違う形なのですが・・・。
最終的にはALTER TABLEとか含めた形にしたいと思っていますが、現状だと皆さ
んが想像してる汎用DBとは違う形のものがファーストリリースになりそうです。
おそらくですが、あるアイテムを自由に項目付けて表示できるっていう程度かな
と思います。対象は1つのテーブルかと。
私の利用想定では、名簿みたいな感じです。
> ・ある程度仕様上に半固定部分が多く、初心者でも利用法が想像できるもの。
> (項目名などを半固定にしてますが、altsysで名称は変えられる。項目数
> は現状固定。)
> ・テンプレートを変更すれば、いろんなことに流用できそうなこと。基本的にはリスティングとデータの検索抽出を目的とする。
> ・軽いこと。
> ・D3であること。
> ・カテゴリは考え方によると思いますが、既存の物にあるようなデータが必ず「ひとつのカテゴリ」に所属するタイプではなく、複数のカテゴリに所属できる
> こと。そのためカテゴリの階層構造は諦めてます。
fabiさんの挙げた条件では、カテゴリの複数所持が一番大変そうですね。
むしろ階層構造のほうが簡単です。
あと、項目を増減させられないと、作ってて面白くないなーと思います。
なぜなら、項目数が決め打ちなのはいつも仕事で作っているので(苦笑)。
こうだったら面白いかなーと思うのは、ある項目についてフォームのデータが
色々とくっついている感じです。(フォームはActionForm使わないとおそらくキツイ)
ある項目━┳━項目名称
┣━項目の入力方法(テキストエリアとか、セレクトタブとか)
┣━項目の入力オプション(セレクトタブのOption項目とか)
┣━項目の入力デフォルト値
┣━項目のカテゴリ━━━━カテゴリテーブル
┣━項目が必須か?
┣━項目は数字縛りか?
┣━項目にインデックスを張るか
┣..........などなど
こういう「ある項目」を増減できるという感じです。
で、入力フォームを作る際ですが、デザイナーにプレースホルダを提示するか、
自動でくみ上げちゃうのかっていう感じかと思います。
前者の場合、
<{form_input name="item_name" size="***"}>
っていうのが「ある項目」の入力フォームになる。デザイナーはこれ使って
ぺたぺたとテンプレを作っていく感じです。
後者の場合、かのXOOPSFORMのように、フォームがワンセット。
<{$form_table}>
みたいなひとつの変数にレンダリングされてしまう感じです。
で、ALTER TABLEを使わない(項目数きめ打ち)方法だと、ひとつのフィールドにシリアライズして
全部つめちゃうとか。これだと検索とか出来ないですね。
# 項目の増減を諦めるなら問題ないですが
さらに、項目数が決め打ちだと、テンプレ変数が
<{$form1}>
<{$form2}>
<{$form3}>....
とかなって、その後の作業に著しい効率の低下が見られそうです。
伊藤
もう見てらっしゃるかもしれませんが、汎用データベースモジュール waffle と
いうのを公開しています。
管理ページでカラムを追加すると内部で ALTER TABLE するようになっています。
http://tokita.net/modules/mydownloads/singlefile.php?cid=1&lid=11
nobu wrote:
> ALTER で増減ってーと、こんなモジュールを先日公開してます。
> (xoopscube.org でしかアナウンスしてないな)
>
> http://mysite.ddo.jp/modules/mydownloads/singlefile.php?lid=23
私も、印象的にはこんな感じです。
XOOPSForm使ってるんですね。デザインに拘り無ければ、
一斉レンダリングで問題ないですよね。
JavaScriptでの値チェックは私もやりたいなーと常々思ってるんですが、
なかなかスマートにやる方法が思いつかず・・。
やっぱりテンプレにScript書いて書いてになるのかな。
伊藤
時田さん、はじめまして。
> もう見てらっしゃるかもしれませんが、汎用データベースモジュール 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プログラム作ることが多かったりします。。。
> おお、ご存知とは、、ありがとうございます。
いえいえ、時田さんくらい色々やってるのはminahitoさんくらいかなぁと
思い記憶に残っております。:)
久しぶりにWaffle見てみました。。
もうこれでいいんじゃないでしょうか、という気になりますね。
しかし、ここはXOOPSCubeであえて作ってみたい気もします。:-p
>> あと、テーブル構造を変えることを前提にすると、フィールド定義を自動で作ってくれる
>> ORMが必須かなという気がしています。SQL書くわけに行かないですよね。
>
> waffle は内部的には以下のような YAML 定義を作成して、いわゆる
> O/R MAP 的にデータにアクセスしています。テーブル構造が変わるとYAML定義が
> 変わり、それに合わせてライブラリ動作します。
> なのでベタなSQLは書かないようになっています。
これは、一端どこかにキャッシュYAMLファイルwを作ってたりするんですか?
内部的に・・・ということなんで、毎回DBからパースしてるんでしょうか?
# 動かしてみたけど、cacheとかにその形跡はないし・・・
伊藤
> 久しぶりにWaffle見てみました。。
> もうこれでいいんじゃないでしょうか、という気になりますね。
うおおおお。
自分がやろうとしてたことが殆ど実装済みどころか、もっと細かいレベルで操作
ができるようになってる。
確かに、これで良いんじゃないでしょうか、と思ってしまいました^^;
> >> あと、テーブル構造を変えることを前提にすると、フィールド定義を自動
で作ってくれる
> >> ORMが必須かなという気がしています。SQL書くわけに行かないですよね。
> >
> > waffle は内部的には以下のような YAML 定義を作成して、いわゆる
> > O/R MAP 的にデータにアクセスしています。テーブル構造が変わるとYAML定
義が
> > 変わり、それに合わせてライブラリ動作します。
> > なのでベタなSQLは書かないようになっています。
やっぱり、テーブル定義の変更って必要なんですかね。。。
伊藤さんも書かれていますが、用途によってはALTER TABLEの最中に書き込みが
あったら、とか考えると定義変更は極力避けたいと思ったりするんですよね。
> Postgresなんかは、ALTERで増やしても削除は出来ないんですよね・・。
> 増やすのもケツにしか付けられないし。
> (8になってできるようになったのかな?)
思わず反応してしまいました(苦笑
いつ頃からかは判りませんが、今のPostgreSQLは、ALTER TABLEで列の削除なん
かも出来るみたいです。
http://www.postgresql.jp/document/pg824doc/html/ddl-alter.html
今朝はXUGJが妙に重いので、ひさびさにMLに投稿します。
> > 久しぶりにWaffle見てみました。。
> > もうこれでいいんじゃないでしょうか、という気になりますね。
>
> うおおおお。
> 自分がやろうとしてたことが殆ど実装済みどころか、もっと細かいレベルで操作
> ができるようになってる。
> 確かに、これで良いんじゃないでしょうか、と思ってしまいました^^;
waffleって、最初に見た時点であまりにも穴だらけだったので、私の中では、
tokitaという名前がブラックリストに入ってました。(ごめんなさい)
今はどうなんでしょうか。
そのあたりがすべて書き直されているなら検討対象になるかもしれませんね。
もっとも話を聞く限り、私の望んでいるものとは正反対のようなので、私は
私で作ると思いますが。
> やっぱり、テーブル定義の変更って必要なんですかね。。。
> 伊藤さんも書かれていますが、用途によってはALTER TABLEの最中に書き込みが
> あったら、とか考えると定義変更は極力避けたいと思ったりするんですよね。
そりゃどんなDBエンジンだって、ALTER中にロックくらいはするでしょう。
私の経験上では、少なくともMySQLでALTERをそこまで避ける必要性は感じま
せんね。最悪壊れてもインデックスくらい。
実際、onupdateあたりでは、ALTERバシバシ使ってますし。
(モジュールアップデートと汎用DBモジュールのフィールド変更とでは、頻
度も同じくらいでしょう)
MySQLの良いところは、テーブルが単純なファイルだってことです(少なくと
もMyISAMは)。バックアップ・リストアも極めて容易なのですから、そんな
に怖がる必要は感じませんね。
ただ、汎用DBを作るためにALTER TABLEっていうのはアイデアとしてあまりに
も安易かなあ、という一点で、私もALTER否定派です。
どこにレスつけるのが適当かなやんだのですが、とりあえずここに。
> > ・カテゴリは考え方によると思いますが、既存の物にあるようなデータが必ず「ひとつのカテゴリ」に所属するタイプではなく、複数のカテゴリに所属できる
> > こと。そのためカテゴリの階層構造は諦めてます。
>
> 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を使わない(項目数きめ打ち)方法だと、ひとつのフィール
> ドにシリアライズして全部つめちゃうとか。これだと検索とか出来ないで
> すね。
そんなことはないですね。文字列検索なら、それこそ、文字列検索用のフィ
ールドを1個用意して、適当なセパレータで検索対象とするフィールドの値
をCONCATして格納しちゃえばいいんです。
数値検索だとそういう訳にはいかないので、その場合はALTER TABLE必須でしょ
う。
同様に、ORDER句の対象とする場合もDBにフィールドを追加するしかないかな
あ、という感じです。
データ更新時に、冗長情報として、アイテムのランキングを保存しておく、
なんていうものすごい技も思いついたのですが、さすがに件数が多くなると、
SQL文長がものすごいことになりそうですね(笑)。
カテゴリーやタグについては、ALTER TABLEというより、CREATE TABLEと
DROP TABLEの組み合わせでしょうかね。カテゴリーテーブルそのものと、リ
ンクテーブルを2つセットで作る。これについては、他の解法はないかな、
という気がしています。
メールを遡って読んでいるので、レスの順番が逆転してしまってすみません。
> ではDevelopers Group なら話を聞いてもらえるだろうということでここに
> 投げます。
私は良い企画だと思います。少なくとも画面を作っている時点でクレクレじゃ
ないですよ。
nobunobuさんの開設意図も、まさにこういうのをやろうってことでしょうし。
tohokuaikiさんも書いてましたが、テンプレートが先に形として見えているっ
ていうのはいいですよね。
モジュール開発する上で一番しんどいのは、HTMLを0から書くことですし。
(少なくとも私はそうです)
しかし、このモジュールトップの構成要素って、XWordsそっくりですね。
カテゴリーで抽出条件が「ABCD...」となるだけ。
もしかして、XWordsなんかも、この汎用DBのサブセットで済んでしまう?
はい!「まさに」です。
(小生が日本を離れていてネットにでれない間にこんなトピックがあがっていたなんて・・・)
「汎用DB」の「汎用」にどこまで求めるかは、人それぞれだとおもいますが、
これさえあれば、他のモジュールいらない(笑)ってな優れものができないかなぁ・・・
冗談はともかくとして、「項目」の考え方については、別途のレスを書かせてもらおうと
おもってます。
( その前にとりあえず「waffle」を評価しないとと考えているのですが・・・^^; )
----------------
Nobuki Kowa
Nob...@Kowa.ORG
----------------
> いえいえ、時田さんくらい色々やってるのはminahitoさんくらいかなぁと
> 思い記憶に残っております。:)
いえとんでんもないです。
> これは、一端どこかにキャッシュYAMLファイルwを作ってたりするんですか?
> 内部的に・・・ということなんで、毎回DBからパースしてるんでしょうか?
> # 動かしてみたけど、cacheとかにその形跡はないし・・・
waffle0_config テーブルにデータテーブルのYAMLとキャッシュデータが入って
います。
また modules/waffle0/yaml/ 以下に waffle 自体のテーブルを操作する
YAMLファイルが入っています。
モジュール内で ALTER TABLE を使うのは、やっぱり自分も最初抵抗がありまし
た。それでも使ったのは、以前仕事で積極的に ALTER を使うシステムを担当し
ていてとくに問題なく安定して運用できたいたのと、素直にカラムを追加した方
が MySQL のパフォーマンスが出ると(そのときは)思ったからでした。
他によい方法が思いつかなかったというのもありますがー。
コンテンツの意味論からのアプローチだと、「カテゴリー」とか「タグ」というのは、
各レコードを分類し、絞込み検索を行って、容易に目的のコンテンツにたどり着く
為に必要なものだと理解していますが。
データベース側からのアプローチからだと、単に
「マスター」データに関係を持つ一項目に過ぎないとです。
上記不動産の場合だと
「新古区分」
「住居携帯」 一戸建て・マンション
「間取り」 ワンルーム・1K・・・・・・・
「地域」 山手線 沿線
「価格帯」 1000千万以下・・・・・
という5つの項目があって、それぞれの項目に値を示すマスターデータが存在する
というだけだとおもいます。
fabiさんの要望の固定数項目でなく本当に、可変汎用にするのであれば、
項目定義時に、項目毎に検索絞込みが可能か、その優先順位は?などを定義し、
その定義内容によって、画面遷移を組み立てるという形の方が、
データベースからのアプローチとしてはまともだと考えます。
この意味で、別途GIJOEさんが、カテゴリーは、
Create Table Drop Tableが必要と書かれていたのだと思いますが、
名称だけが必要だったりする分には、別に新しいテーブルでなく、
汎用の名称引き専用マスタを用意しておくだけでも良いかもしれません。
もちろん、今までの議論の中にも出てきているように 項目によって、
マスタとの関係が「1:n」(単一選択)か「n:n](複数選択化)とか
マスタ内データの階層化をどのようにするかとかも考えないと
いけないですが、こちらは、マスターの扱いをうまくカプセル化してやれば
マスターの定義やリンクテーブルの定義側の変更だけで
済ますことも出来なくは無いと思います。
まぁ、ここまで重装備にするかどうかは別ですが、ご参考まで。
07/11/22 に fabi<mino...@gmail.com> さんは書きました:
> waffleは自由度としてはほぼ満点に近いんじゃないかと思います。「カテゴリ」の観念を持たないのは私と同じです。
> しかし、これはその自由度ゆえにか、構築前にちゃんと設計をしないといけないんですよね。その操作も煩雑で、ある程度の知識が必要です。
> 家計簿を自分で作るときにエクセルのまっさらなシートを前に途方にくれる感覚に近いです。
>
> 対してADDBOOKは、ある程度サンプルとしてのデータが入っていることもあってか、直感的に出来上がりが頭の中で想像できます。私としてはこちらの
> 方の路線を継承して、比較的簡単に誰でもデータベースサイトを構築できるということを目標にしています。
Waffleはサンプルもありますよ。
サンプルを生成してしまうとそれまで作ったデータテーブルはなくなってしまいますが、
これの考え方は便利だと思いました。
つまり、プリセットを用意しておいて、必要ならそれをLoadするという。
Duplicateに作っておけば別にモジュールインストールして
サンプルをロードすれば良いですからね。(WaffleもD2)
伊藤
>> これは、一端どこかにキャッシュYAMLファイルwを作ってたりするんですか?
>> 内部的に・・・ということなんで、毎回DBからパースしてるんでしょうか?
>> # 動かしてみたけど、cacheとかにその形跡はないし・・・
>
> waffle0_config テーブルにデータテーブルのYAMLとキャッシュデータが入って
> います。
おぉ!そんなところに。。
> モジュール内で ALTER TABLE を使うのは、やっぱり自分も最初抵抗がありまし
> た。それでも使ったのは、以前仕事で積極的に ALTER を使うシステムを担当し
> ていてとくに問題なく安定して運用できたいたのと、素直にカラムを追加した方
> が MySQL のパフォーマンスが出ると(そのときは)思ったからでした。
> 他によい方法が思いつかなかったというのもありますがー。
うーむ、こんな感じでしょうか。
ALTER抵抗ある派
┃
┣テーブルが壊れちゃうんじゃないか(伊藤)
┃ ┃
┃ ┣━やってみたら意外と平気(時田)
┃ ┃
┃ ┗━MySQLのロックなんて信じないよう(gusagi)
┃
┗━そもそもALTERなんて安直過ぎて面白くないよ(GIJOE)
私、以前にADDBOOKでALTER使わずにやってみたんですが、もうやりたくないってのが
本音です。頭がこんがらがりました。
伊藤
一言レスですが・・・・
小生は、「別にALTER TABLE使っても良いんで無いの?」派です。
但し、原則として、(GIJOEさんが書かれていたのとほほ同じですが)
・項目の定義変更の機会はそれほど無い
・モジュールのアップデートと同様で、DBMSに信頼が置けないなら、
サイトの重要度によっては、深夜にサイトクローズしてやれば良い
・もっと慎重にやるなら、事前にバックアップとって置けば良い
っていう運用を前提とするということです。
なので、究極のユーザビリティーを求めるなら、モジュール管理側で
バックアップ・リストア機能あると安心度は高まるかと。
どうせ、項目増やす場合には、デザイン重視サイトならテンプレートも
変更するでしょうし、あんまりオンライン状態のままで定義変更なんて
シーンは思い浮かばないのですが・・・
別の設計として、あまり検索頻度が高くないような属性項目は、
別途下記項目を持つ属性専用テーブルを用意するってのもありだとは思います。
「主テーブルのレコードID」
「項目名」
「項目値(数値)」
「項目値(文字列)」 ・・・項目タイプによってフィールドを分けるかどうかは要検討
この場合でも、項目定義に変更があった場合には、何らかの形で、このテーブルの
データ一括処理が必要になるわけですから・・・
結局運用負荷は、あんまり変わらないのではと思いますが・・・
ALTERを使うかどうかとは別次元の問題で、こういう項目管理は私の好みじゃ
ないですね。
まるっきり、Liaiseとか白扇と同レベルじゃないですか。
こういうのって、結構細かい手間がかかる割に、フォーム作成の自由度を奪
うだけの設計なので、作ってて面白くなるとは思えません。(私にとって
XOOPSはあくまで趣味なので、面白いかどうかがモチベーションと直結します)
フォーム設計(フィールド定義)をブラウザでやるっていうのもストレスが
たまるだけという気がします。それだったらXMLで定義を書いてCubson使う方
が、はるかに「汎用DB」という意味に近い気がしますね。
それをやったら、XCL専用になってしまうのでやりませんけど。
昔と比べて今では、大量データの処理能力が格段に上がっています。
だから、テーブルのカラムそのものは増減しないけど、固定数の冗長カラム
に巨大なデータを突っ込んでうまく処理する、なんて方法なら作っていて楽
しいかな、なんて考えてます。
> 家計簿を自分で作るときにエクセルのまっさらなシートを前に途方にくれ
> る感覚に近いです。
だから、まさにエクセルシートを添付すればいいんですよ。
フィールド定義とか初期値設定を、ブラウザでやるなんてナンセンスです。
1テーブルを処理するなら、表計算アプリケーション以上のツールはありま
せん。
そのシートをアップロードしてもらう。
それがそのままフィールド定義にもなるし、初期値にもなる。
ダウンロードもxlsにすれば、ダウンしてデータ書き換えてアップロードとい
う流れも、CSVよりスムーズです。(CSVだとカラム幅とか表示形式情報がな
いのが痛い)
…という設計で、Excelのxlsファイル(ただしXML形式)をやりとりするイン
ターフェースを途中まで作ったことはあります。(1~2年前)
どうして挫折したかというと、Excelに貼り付けた画像を取り出す方法が見つ
からなくて嫌になったという…
画像もフィールドに貼り付けたものをそのまま反映させたいじゃないですか。
でも、XML形式だと画像を含められないし、バイナリ形式だと解析が死ぬほど
面倒……orz
突っ込もうと思ってたら、のぶのぶさんに先を越されてました。
しかも、fabiさんのサンプルサイトのカテゴリー管理画面さえもすでに書き
換わってます(笑)
不動産情報だと、15~6個はマスタがありますね。
そして、多対多も多対一もありますし、階層構造があるものもあります。
多対一の階層構造例:住所
東京都-千代田区-一番町1丁目
多対多の階層構造例:最寄り駅
半蔵門線-半蔵門駅
有楽町線-麹町駅
いろいろな意味で、相当にハードルが高いでしょうが、これをすべて実装で
きたなら、ほとんどのカテゴリー構造を再現できると言えるでしょう。
リレーションの正規化なんてのを今さら論じるつもりはありませんが、やっ
ぱりそういうルールをある程度守った方が最終的に使いやすいのは確かだと
思います。
あと、価格帯なんてのは逆にカテゴリーになりませんよね。
価格の従属条件に過ぎませんから。
> 名称だけが必要だったりする分には、別に新しいテーブルでなく、
> 汎用の名称引き専用マスタを用意しておくだけでも良いかもしれません。
これが私のイメージするタグですね。
タグなんかはそれこそ固定で1つ持っておいても良いかもしれません。
タグを2種類以上設定する状況ってありますか?
「汎用」とは少し離れますが・・・
最近、ある新サイト公開用にモジュールを書いているのですが、
この開発に、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さんが書いていた文章だったなーと、それが書きたかっただ
けだったり。とても参考にさせてもらいました。
> モジュールインストールとモジュールアップデートとで別々のSQLやバージョ
> ンの判定ロジックを組み込むのが面倒なため、SQLを組み込むための定義を
> PHPで書いてやり、これを読み込むことによって、モジュールインストール
> 時のテーブル生成、モジュールアップデート時のALTER文生成も自動で行い、
> 別途XOOPSFormベースのカストマイズ可能な自動フォーム生成と組み合わせ
> ると、XOOPS_TRUST_PATH下の定義に対してXOOPS_ROOT_PATHのモジュールデ
> ィレクトリ下に項目追加を行った独自のテーブル定義をおいてやれば、管
> 理画面でのメンテに関しては、自動的に追加した項目を反映できるなんて
> 事ができるようになりました。
これって、リクエスト毎にそういう処理を行うのでしょうか?
であれば確かに重くなりそうな気はしますが、XCL2.1も十分に重量級なので、
気にするレベルじゃないかもかもしれません。
私が考えているのは、Smartyのコード版っていうんでしょうか。
PHPフレームワーク的に書いたものを、PHPベタコードにコンパイルして、コ
ンパイルキャッシュを作成し、リクエスト毎には、そのコンパイルキャッシュ
を実行するというタイプです。
XCLに対してアクセラレータなどを使うと妙に速くなりますが、アクセラレー
タの効果が一番大きいのはクラス解析のようです。(自分で実験した限り)
かといって、アクセラレータは副作用が消せない。
だから、フレームワークものをベタコードに展開すれば、相当に速くなるん
じゃないかな、なんて考えてます。アクセラレータと違うのは、おかしな動
作があっても、ベタコードを追いかければとりあえず自分でデバッグができ
る、という一点。
開発はフレームワーク、実行はベタコード、といういいとこ取りで :-)
……でも、これって、Cコンパイラを作るのと同じ労力がかかる?
> これで、D3モジュールの、テーブル定義、テンプレート定義、言語定数定
> 義すべてモジュール固有の定義オーバーライドが可能になるので、モジュ
> ールに対してかなりの自由度付与ができると思います。
> (これらの定義の一部はALTSYS併用によってさらに便利になります)
このあたりは実装を見るのが楽しみですね!
# 旧NBFrame、読まなきゃと積んであります(汗
# 新NBFrameこそは読むぞ!
時田さん、こんにちは。
> あの時は失礼しました。
いえいえ。こちらこそ失礼しました。
腕も伴ってないくせに、口の悪さだけは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を組み込んだ
場合にうまく読み込めない。modhinfo.phpだけ対応するロジックになっている。
通常のモジュールだとmain.php admin.phpに定義された定数をモジュールの
ロジック内で固定で使用することが多いのでこのような使用をすることがまれだと
思いますが、NBFrameでは、定数直使用を行わない方式をとっているので、
dirname単位での言語管理を可能にしています。
ってなところが何とかなれば、相性ばっちりなんですが・・・
---------
のぶのぶ
---------
すっかり化石レスにて恐縮ですが…
> いや、あくまでもモジュールインストトール及びモジュールアップデート時の動作です。
> 従来の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を組み込んだ
> 場合にうまく読み込めない。modhinfo.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ファイルだけ除外して配布するっていう手もありますが・・)
ポップアップウィンドウ用とか、X2でいうnocommonプログラムとかをあまり区別することなく、
それぞれを、Action Classsとして実装できるようにしているので、かなり開発を楽にすることができました。