株式会社ロックオンの梶原です。

突然ですが、カスタムフィールド機能を追加したいと思います。

まずはチケットを作成しました。
http://svn.ec-cube.net/open_trac/ticket/817

【経緯】
現状、商品情報や顧客情報にフィールド追加をしようとした場合、フロント画面、管理画面、CSV等
色々なところをカスタマイズしないといけません。
これは、かなり不便だと思います。

ということで、管理画面よりフィールドの追加ができるよう機能追加をしたいと思います。

【仕様】
簡易な設計変更と2系のカスタマイズ性を損なわないために、以下のような仕様を想定しています。
（難しい仕様も検討してみたのですが、カスタマイズ性が損なわれる可能性が大いにありましたので、
最も簡易な実装でいきたいと思っています。）

　・現商品DB、顧客DBに予め個数限定でカスタム用のフィールドを追加し、そちらを使用する。
　　（上限10個あたりを想定）

　・カスタムフィールド用の管理機能をそれぞれ商品管理、顧客管理に追加する。

トラックに簡単な画面仕様書（商品DB部分のみ）をつけてみましたので、ご確認いただき、
よろしければご意見いただければと思います。

【開発形態】
本機能に関しては、かなり色々な仕様が考えられるため、とりあえずコミットしてから、その後、
より便利な機能になるように修正していくようなステップで開発していければと思っています。


以上、まずは意思表明まで。

カスタムフィールド、いいですねぇ！個人的には
無制限に欲しいです。数を限定してしまうと、
サブ情報を増やしたい時と同じような状態に
なってしまいそうなので…。

すごく求めている人も多い機能かと思うので、とてもありがたい機能になるのではないでしょうか。

ただやはり上限制限付きでは、もったいない気がしますね。

できればデフォルトで用意したフィールドではなく、フィールド追加時のみ追加され、削除時には削除される仕様が無駄がなくて、汎用性が高いかと思います。

ただそうすることで簡易的という前提が崩れてしまいますね…

http://www.kudzilla.com/~hic/eccube-dev/
ID/PWD : hic/Ringo
250-company_section_kiban.pdf
250-company_section_kiban-admin.pdf
をまとめてみた小生としては

引用：
そう言わず
1.既存テーブル：dtb_customerに「拡張フラグ」フィールドを設ける。
2.テーブルを一つ起こす。ex：dtb_customer_extend
3.ex：dtb_customer_extendに想定されるフィールドを作成
　ex：
　1)項目名
　2)属性
　　a)フルテキスト
　　b)カナ
　　c)数字
　　d)英字
　　e)英数
　　f)ラジオボタン,チェックボックスと名称
　　g)必須
　　h)など、など
　3)表示属性
　　a)表示順位
　　b)など、など
　などなど
とし、カスタマイズは従来通りex：dtb_customer_extndへのフィールド追加andロジック,表示処理追加
まで、持っていった方がよいのではないでしょうか？

が、

「難しい仕様も検討してみたのですが、カスタマイズ性が損なわれる可能性が大いにありましたの」

であったのでしたならば「失礼しました」、、、です。。。

ダウンロード系やアップロード系、その他各種機能へのインパクトを考えると、簡易な梶原さんの案を支持したいです。

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h

拡張性を向上させる事自体は大歓迎ですが、半端な仕様であれば無いほうがマシです。

上限10個で不足したら結局いまと変わりません。
モジュールがカスタムフィールドを使用する可能性を考慮した場合、注文データのmemo**のような怖くて触れないuntouchableな領域が増えるだけという事になってしまう気がします。

また、仮に上限無制限にしたとしても、商品のサブ情報などの既存部分が現行仕様のままであれば意味が無い、とまでは言いませんが、ありがたみは薄いです。

そもそも、ある意味成熟し切った現行の２系に各種機能へのインパクトが不安になる機能を追加するのも如何かと思います。
「２系のカスタマイズ性を損なわないために」安易にならざるを得ないのであれば、３系として再設計する時期が来たと言う事では無いでしょうか。

とにかく既存部分が現行仕様のままなら反対。

----------------
pantacle
http://pantacle.net/

本件、
商品情報：dtb_products系
顧客情報：dtb_customer系
が同時に「意思表明」されています。

pantacle様が言われる
「とにかく既存部分が現行仕様のままなら反対。」
は、主に「商品情報」の処理に対してと理解しました。

カスタマイズの要望は「商品情報」「顧客情報」別々に生じるとして、
「顧客情報」に対しても

「とにかく既存部分が現行仕様のままなら反対。」

と理解してよろしいでしょうか？

商品や顧客が, モデルクラスとして管理されていれば良いのですが, 現行の SQL 直書き状態で, 更に複雑に JOIN するテーブルが増えると恐怖を覚えるので,

* 現行テーブルに拡張用のカラムを追加
* 拡張用カラムのフィールド型を定義するテーブルを追加

といった感じの実装を考えています.

個人的な意見としては, カラムを追加した場合に最小限の変更で済むように, O/R Mapper の採用を推したいんですけどね

http://svn.ec-cube.net/open_trac/ticket/555

これはこれで, 風当たり強くてなかなか進まないのですが(汗)

ちょうど「使わない項目をなくしたい」という要望の為にあちこち触っているところだったので、ちょっと書き方が乱暴だったかもしれません。

> カスタマイズの要望は「商品情報」「顧客情報」別々に生じるとして、
> 「顧客情報」に対しても
>
> 「とにかく既存部分が現行仕様のままなら反対。」
>
> と理解してよろしいでしょうか？

機能単位の話をしているつもりはありませんが、仮に「顧客情報」のみを対象にするとしても、上限10個で不足したら？等の懸念に変わりは有りません。

10個に決める根拠は何？とか追求してみたいところではありますが、カスタムフィールドをやるのであればRingoさんが提案されたような拡張テーブルで処理するのが妥当と思います。
が、どうするにしても実際に「使わない項目を」というニーズがあるわけで、カスタムフィールド的な機能が無かったが故に、「機能には必要では無いけれどもあらかじめ用意されている項目」の見直しも必要であろうと思うのです。

----------------
pantacle
http://pantacle.net/

> 個人的な意見としては, カラムを追加した場合に最小限の変更で済むように, O/R Mapper の採用を推したいんですけどね

妥当なアプローチだと思いますが、変更を全体に行き渡らせるには作り直しに等しいかそれ以上の手間が掛かりそう...。

----------------
pantacle
http://pantacle.net/