localflavor-ja
tsuyuki makoto
開発SVN版に、localflavorというコントリビュートパッケージができました。
地域に関連したものはこの中に入ることになるようです。
usaに続き、ukが登場したのでjpもぜひとも入れたいと思っています。
まずは、郵便番号と都道府県に関するものを書いてみました。
newformsの中を始めてまともに見たので、どんどん突っ込んでください。
django.contrib.localflavor.jpの直下に置くことを想定しています。
つづいて、電話番号に関するものを書く予定ですが、ちょっと人生が辛い
のですぐには書けないかもしれません。
＃コメントやテスト・ドキュメントも書かないと…
Yasushi Masuda
ざっと見ですが，コード拝見しました．
1. models.py は不要だと思います． CharField には validator_list を指定できるので，
実質的には CharField(validator_list=[isValidJPPostalCode])と同じだからです．
choices=JP_PREFECTURES も同様です． localflavor の提供するバリデータやサービス
データに isValidJPPostalCode や JP_PREFECTURESがあるとドキュメントに明記されて
いれば十分だと思います．
2. validator のバリデータは，旧番号体系，新番号体系，両方に対応可の 3 種類が
用意されていて，それぞれが別個の正規表現を使っています．この，両方に対応可
のバリデータは，内部で前者の二つを試して，例えば旧番号->新番号にフォール
バックしてバリデーションしてはどうでしょう．また， validator で定義している
正規表現ですが， 3. で述べる理由から， public なモジュール変数にしては
どうでしょう．あと，統一性から _jp_postal_... は jp_postalcode_... または
jp_postal_code_ ... が良いと思います (standard 的には後者だと思います)
3. forms の JPPostalCodeField は，contrib/localflavors/us/forms.py の
USZipCodeField のように， RegexField を継承してはどうでしょう．その際，
デフォルトの正規表現を validators から import して使います．例えば，
from validators import jp_postal_code_newformat_re
class JPPostalCodeField(RegexField):
def __init__(self, pattern=jp_postal_code_newformat_re, *args, **kwargs):
super(JPPostalCodeField, self).__init__(pattern, ...)
のようにするわけです．これなら， clean() の処理は RegexField 任せにできます．
--
Yasushi Masuda
http://ymasuda.jp/
tsuyuki makoto
増田さん、いつもありがとうございます:)
> 1. models.py は不要だと思います． CharField には validator_list を指定できるので，
> 実質的には CharField(validator_list=[isValidJPPostalCode])と同じだからです．
> choices=JP_PREFECTURES も同様です． localflavor の提供するバリデータやサービス
> データに isValidJPPostalCode や JP_PREFECTURESがあるとドキュメントに明記されて
> いれば十分だと思います．
validator_listやchoicesがform_for_modelによって生成されるFormで利用されない
ので、無理矢理フィールドを作ったのですが考えてみればnewformsはまだ実装中
でしたね。
validator_listやchoicesでvalidationされるようになるのを待ちます(=modelはいらない)。
実は、まだnewformsやnewadminの使い方をよく認識していません…
SomeForm = form_for_model(Some)
SomeForm.attr_a = JPPostalCodeField(pattern=jp_postal_code_newformat_re,
error_message='なんとか')
こんな感じにフォームを定義して、ビュー毎にどのフォームを使うかを設定する
のかな？モデルにデフォルト設定とかできるのかな？
＃モデルになんても書くスタイルが気に入っていたので、newformsはちょっと気に入らない:)
なので、いまのところusaやukでやっていること以上をやるのは時期尚早だったと
反省しましたorz
> 2. validator のバリデータは，旧番号体系，新番号体系，両方に対応可の 3 種類が
> 用意されていて，それぞれが別個の正規表現を使っています．この，両方に対応可
> のバリデータは，内部で前者の二つを試して，例えば旧番号->新番号にフォール
> バックしてバリデーションしてはどうでしょう．また， validator で定義している
> 正規表現ですが， 3. で述べる理由から， public なモジュール変数にしては
> どうでしょう．あと，統一性から _jp_postal_... は jp_postalcode_... または
> jp_postal_code_ ... が良いと思います (standard 的には後者だと思います)
2種類にした方がわかりやすいし、DRY!って言えていい気がします。
が、2種類にしてしまうと、JPPostalCodeFieldをRegexFieldの継承にするときに
困ってしまうような気がしています。
はて
> 3. forms の JPPostalCodeField は，contrib/localflavors/us/forms.py の
> USZipCodeField のように， RegexField を継承してはどうでしょう．その際，
> デフォルトの正規表現を validators から import して使います．例えば，
> from validators import jp_postal_code_newformat_re
> class JPPostalCodeField(RegexField):
> def __init__(self, pattern=jp_postal_code_newformat_re, *args, **kwargs):
> super(JPPostalCodeField, self).__init__(pattern, ...)
> のようにするわけです．これなら， clean() の処理は RegexField 任せにできます．
validatorを使わないと、毎回error_messageを渡さなければいけないなと
思ったのがRegexFieldを使わなかった理由です。
が、エラーメッセージ位書けばいい気もしますし、validatorと同じ文字列を利用
できるようにしてもいいとも思います。
ふむ…
ちょいと再挑戦します。