Ticket #651 (new 改善提案)

Opened 14 years ago

Last modified 12 years ago

バリデーションを適切に行なう

Reported by: Seasoft Owned by: somebody
Priority: Milestone: バックログ
Component: その他 Version: コミュニティ (eccube-comu)
Keywords: Cc:
修正済み: no

Description

本チケットでは、下記のような改修を扱う。

  • 同一項目を画面によって異なる基準でチェックしているものを統一する。
  • 不適切な基準でチェックしているものを正しくする。
  • より適当な基準でチェックする。
  • チェック漏れを無くす。

Change History

comment:1 follow-up: ↓ 2 Changed 14 years ago by nanasess

チェックロジックを一箇所にまとめたいです

comment:2 in reply to: ↑ 1 ; follow-up: ↓ 3 Changed 14 years ago by Seasoft

nanasess への返信

チェックロジックを一箇所にまとめたいです

具体例がありましたら、記載いただけると助かります。

個人的には、SC_FormParam#checkError と SC_CheckError の使い分けを明確にしたいと、前々から気になっているというのがあります。

他にも、最終的にエラー(バリデーションの結果)を出力するときまで、(現在の配列ではなく) オブジェクトで持ちまわりたいというのもありますが、話しがやや大きくなり過ぎますかね。せめて「※」や改行は表示する側でコントロールしたいなぁ・・・と感じています。

あと、下記も若干気になっていた部分です。
 http://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=6674&forum=1

エラー文言(Smarty変数「$arrErr」)って、HTML の必要性あるのかなぁ・・・というのも。 一歩間違えれば、XSS にも繋がるような。

(備忘録的に色々と書いてしまいました。)

comment:3 in reply to: ↑ 2 ; follow-up: ↓ 5 Changed 14 years ago by nanasess

Seasoft への返信

チェックロジックを一箇所にまとめたいです

具体例がありましたら、記載いただけると助かります。

チェックの宣言が各ページクラスに分散しているので, 一箇所にまとめたいです. ある程度, 宣言的にまとめられれば, Excel などで管理し, マクロでコードを自動生成もできるので.

個人的には、SC_FormParam#checkError と SC_CheckError の使い分けを明確にしたいと、前々から気になっているというのがあります。

SC_DbConn と SC_Query の場合と同様で, おそらく SC_FormParam は後から作ったものだと思います. 今後は SC_FormParam のみを使う方向で良いのではないでしょうか.

他にも、最終的にエラー(バリデーションの結果)を出力するときまで、(現在の配列ではなく) オブジェクトで持ちまわりたいというのもありますが、話しがやや大きくなり過ぎますかね。せめて「※」や改行は表示する側でコントロールしたいなぁ・・・と感じています。

賛成です.

あと、下記も若干気になっていた部分です。
 http://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=6674&forum=1

コメント追記しましたが, 煩わしい関数なので廃止してしまっても良いかなと.

エラー文言(Smarty変数「$arrErr」)って、HTML の必要性あるのかなぁ・・・というのも。 一歩間違えれば、XSS にも繋がるような。

HTML で返す必要は無いですね. View 側でコントロールすべきだと思います.

エラー文言を JSON で返そうとしたら, parse できなくて, はまったことがあります(苦笑)

comment:4 Changed 14 years ago by Seasoft

コミット済みチェンジセット

comment:5 in reply to: ↑ 3 ; follow-up: ↓ 6 Changed 14 years ago by Seasoft

チェックロジックを一箇所にまとめたいです

具体例がありましたら、記載いただけると助かります。

チェックの宣言が各ページクラスに分散しているので, 一箇所にまとめたいです. ある程度, 宣言的にまとめられれば, Excel などで管理し, マクロでコードを自動生成もできるので.

たとえば、現状では dtb_customer.name01 のチェックを LC_Page_Entry と LC_Page_Mypage_Change で行なっていますが、これを1箇所に集約して、各ページクラスは集約先を呼び出すという考え方でしょうか?

comment:6 in reply to: ↑ 5 Changed 14 years ago by nanasess

Seasoft への返信

チェックロジックを一箇所にまとめたいです

具体例がありましたら、記載いただけると助かります。

チェックの宣言が各ページクラスに分散しているので, 一箇所にまとめたいです. ある程度, 宣言的にまとめられれば, Excel などで管理し, マクロでコードを自動生成もできるので.

たとえば、現状では dtb_customer.name01 のチェックを LC_Page_Entry と LC_Page_Mypage_Change で行なっていますが、これを1箇所に集約して、各ページクラスは集約先を呼び出すという考え方でしょうか?

はい, そのような認識です.

comment:7 Changed 13 years ago by nanasess

  • Milestone changed from EC-CUBE2.5.0beta to EC-CUBE2.5.1(仮)

comment:8 Changed 13 years ago by kotani

  • 修正済み unset
  • Milestone changed from EC-CUBE2.11.1 to EC-CUBE2.12.0(仮)

comment:9 Changed 12 years ago by kajiwara

  • Type changed from バグ指摘 to 改善提案
  • Milestone changed from EC-CUBE2.12.0alpha to バックログ

改善提案として、一旦バックログに移動します。

Note: See TracTickets for help on using tickets.