そもそも「～をするための～個の～」などのタイトルをつけるのは嫌いだ。個数なんかどうでもよい。
というわけで本題だ。
フォームにデータを入力する際/させる際、まず大原則として以下の2個が上げられると思う。
- 可能な限りデータベーステーブルに沿った形で正しいデータを入力して欲しい
- 可能な限り入力したくない
例を挙げよう。住所を入力しなくてはならない場合を想定してみると、欲しい情報としては、
- 郵便番号
- 都道府県
- 市区町村
- 番地
- 建物名
よって、多くの開発者は、この各項目ごとにデータベースフィールドを作成すると思う。
たとえば、SomeApp.Addressesテーブルに
- postal_code1
- postal_code2
- city
- town
- address
- buildings
別にこれは俺も良くやる。
都道府県や市区町村にマスタテーブルを用意するなら、int型にして番号を選ばせる。
それはいいとして、ただ、問題はインタフェースだ。
もしデータベーステーブルの項目にあわせ。入力フォームがいくつにもなった場合を考えてみる。
仮に郵便番号が前半、後半で別れていた場合、
郵便番号 [ ]
- 123-0001と入力
郵便番号 [ ]-[ ]
- 123入力
- 確定、フォーム移動
- 0001入力
なので俺は、郵便番号を入力させる場合、必ずフォームは1個にしている。
バリデーションは正規表現を使っていくらでも出来るし、PHPだと全角、半角も簡単にコンバートできるので、半角数字だけ、半角数字とハイフンだけ、とフォームに注意書きをすることも無い。
さらに考えると、仮にデータベースに全角で１２３－０００１と入力されたとしよう。もちろんフィールドタイプはvarcharになると思うが、この場合、何が問題になるのだろうか。
たとえば住所などの個人情報を一覧でcsvでダウンロードし、それに対して何らかの処理を行う人は、大抵管理や経理だったりするわけだ。
彼らが
おいおい、数字が全角じゃないか、これでは管理できんよと言うわけが無い。 全角だろうが半角だろうが数字は数字。正しくは数字のシェイプを表示した記号と言うことだ。使う人が目で見て認識できればそれで良い。
なので、郵便番号は1つのフォーム、且つ簡単なバリデーションでOKではないか。
長年Oracleでミッションクリティカルな業務をしてきた人間からは、もしかしたら鼻で笑われるかもしれないが、ミッションクリティカルなWebアプリなんか、その言葉自体が矛盾している。
というわけで、ただの割り切りだが、俺は可能な限りフォームを少なくするようにしている。
郵便番号の話のついでに、誕生日などの日付入力も考えてみる。
前提としてJavaScriptが必須になるが、基本的に日付も1つのフォームで入力させている。
たとえば、
年月日は「年-月-日」で入力してくださいと書いておくのだが、実はフォームをクリックするとカレンダーが表示され、ユーザは全てマウスのみで年月日を日付として入力することが出来るわけだ。
もちろんJavaScriptライブラリの力ははずせない。
肥大化しすぎ且つコアな宗教戦争にまでなりつつあるprototype.js対jQueryだが、どう考えても俺にはjQueryがあっているので、jQueryで使えるdatepickerというカレンダーライブラリで、簡単に実装することが出来る。
極端な話、
- 郵便番号
- 都道府県
- 市区町村
- 番地
- 建物名
開発工数もかなり減るだろう。
幸いにもCakePHPなどに代表させるPHPフレームワークには、入力されたデータが悪意のあるコードであろうと、エスケープしてくれる機能が実装されている。セキュリティ的にも大きなリスクはないと思っている。
それでも「そんなんじゃダメだ！笑っちまうよ！」という人がいれば、その人はWebアプリ開発には向いてないと思う。老舗の開発専門会社でゲーム開発や銀行のシステムでも作っていれば良い。
同じ開発という分野でも、Webアプリ開発はミッションクリティカル前提ではまずい。
それは技術的な部分ではなく、多くは会社の都合が半分以上を占めているから。
そういった「現実」をちゃんと考え、「理想」を追い求めるというスタンスを保っていると自分では思うし、もちろんセキュリティだって高めたい。ただ、それをやるコストは大抵最初からないのである。
そういった状況をあらかじめ理解した上で、家族を食わすために開発を生業としているわけだ。
理想論だけじゃ喰えない。それは青ちょびて色あせた、ただの幻想でしかない。
というわけで、最後に多少雑音が入ったが、今後も入力フォームの数は出来るだけ減らしたい。
facebook
twitter
google+
fb share