るきへなWeblog

MVC分離しろ！

　某Webアプリケーションで、データの登録・削除はできるが、修正機能が無いものがあった。修正したい場合は削除してから登録しなおす。しかし、データ量が多いと再入力の手間がもったいない。ということでユーザーが修正機能を希望した。

　閲覧機能と登録機能を混ぜて作成した。閲覧機能で修正前のデータをとってきてフォームに表示し、その後は登録機能に投げる。

　しかし、バグを入れてしまった。

　閲覧機能では、空文字列をテーブルに表示した際にレイアウトが崩れるのを防ぐため、データが空文字列なら全角スペースに置き換える処理が入っていた。それをそのままコピペしたため、修正機能を使ったときにフォームに全角スペースを突っ込んでしまい、意図せずに全角スペースへ修正されてしまう。

　「空文字列を全角スペースに置き換える処理」は、HTMLの都合でそうするのだから、MVC でいうところの View でやるものだと思う。しかし、Model部分で行っていた。元のプログラムがViewでやっていたのなら、ボクもその余計な処理に気づいて削除していただろう。

　このWebアプリケーションは、某社独自のフレームワークを利用しており、そのフレームワークはMVC分離を強く思想に盛り込んだものである。しかし、プログラマがそれを理解せずにコーディングしたからボクがバグを入れ込んじゃったじゃないか！！

　当時の某社はXMLに強く傾倒していたため、フレームワークのViewにXSLを採用した。XSLさえ習得すればカンタン♪ みたいな宣伝文句だったが、XSLはそうカンタンじゃない。というか仕様が簡単すぎてループを回すだけなのにループ構文が無いから再帰呼び出しで制約を回避する必要があったりして、それはもう大変である。

　あるデータが空文字列だったら、全角スペースなり   なりに変換して出力することもXSLで可能だと思うが、Model側でやっちゃえばカンタンだし高速だし、って思うプログラマの気持ちも分からなくはない。

　Viewの部分でラクにHTMLの都合に合わせた変換ができればよいと思う。今回の空文字列の変換とか、不等号などの変換とかをViewで行えたら、プログラマも積極的にViewで行うと思う。そしてそれはWebアプリケーションのセキュリティホール(クロスサイトスクリプティングとか)を作りこんでしまうリスクの軽減にもなるのではないだろうか。