minahitoの鯉日記スマートフォン用の表示で見るminahitoの鯉日記この広告は、90日以上更新していないブログに表示しています。エンティティモデル(1)#xoopscubecube.jpで、簡単にフィールドを追加可能なテーブルについて話題が挙がっています。同様の機能が実装されています。モジュールをインストールしたユーザーがある程度フィールドを拡張できれば、モジュールを色々な用途に使うことができるでしょう。行為と割り切れば、振る舞い(機能)と、その振る舞いに強く結びついたフィールドの編集をロックすることで、大まかな問題をクリアにすることができます。これまで何度か可変テーブルに関する議論がありました。いった技術は各モジュールでそれぞれ実装するのではなく、ライブラリとして提供され、モジュールの開発者はそれを使うだけでよい、という形をとることが望ましいでしょう。そのうえで、主要な検討項目として、まず以下の3つを挙げることができると思います。データモデルで統一するのか、それとも選択式にするのか。システムが提供するシステムAPIになるのか、システムパッケージが実装モジュールを提供するのか。フィールドを増やすのか。ように、動的で仮想なテーブルのみを持つようにするのか。システム(BASE)パッケージが実装モジュールを提供、あるいは標準提供なし。どの実装で用いられるかはどのモジュールを使うかで決まる。いう形に持っていくのが良いのではないかと考え始めています。選択式にすることで、データモデルをテーブルの完全なバインダとして扱いたい開発者のポリシーを保障することができます。パフォーマンスを重視する開発者や、SQLを使って複雑な処理をRDBMSにリクエストできる開発者には重要なことだと思います。次に、インターフェイスと実装を分けるのはモジュール設計として当然であると同時に、適用の広さと最適化のバランスをユーザーが選択することができます。用いる方式が、レンタルサーバーによっては使用できないというケースです。同じ実装を採った場合、自由度と引き換えに、モデルをまったく変更しないユーザーにも遅い動作を強いることになります。実装を採れば、一部のユーザーはカスタムフィールド的なフィーチャーを一切使用できなくなるでしょう。実装部をモジュール化すれば、ユーザーが希望に応じた実装を選択して導入することができます。それはつまり、このデータモデルを取り扱うAPIは公約数的なものになるということです。?XCのデータモデルはデータソースをRDBMSに絞らない方向で設計される予定ですので、少なくともそことの齟齬はありません。以上は、データソース特有の操作を隠蔽したライブラリ環境下で成立する話です。書きたいという開発者は、別途ライブラリを用意したり、自前で実装することができます。ライブラリ化するといっても、あくまでアプリケーション用ライブラリであって、ハードウェアAPIではありませんので、用意しなければ直ちに開発者から選択肢が奪われる、というものではありません。これはXOOPSファミリの伝統的な選択と言えます。モデルのデータはそこまで頻繁に更新されないという前提で作られています。フォーラムさえ非固定なテーブルで、テンプレートでトピックを表示する仕掛けはかなり面白いです。»プロフィールid:minahito_carp今年こそ広島が優勝したブログ。(1)はてなブログをはじめよう!minahito_carpさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。