カテゴリー

最新の記事

最近のコメント

最近のトラックバック

月別アーカイブ

ブログ検索

RSSフィード

ブロとも申請フォーム

この人とブロともになる

スポンサーサイト

スポンサー広告
--.--.--
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
にほんブログ村 ベンチャーブログへ

PHPフレームワークもどき「PnF」(2)~開発の背景

PHP
2008.11.24
それではなぜ「PnF」を開発しようと考えたのでしょうか。ふたつの理由があります。

理由1:モーダル型Webアプリケーションへの疑問

ひとつは、現在のWebサイトの多くが「モーダル型」である点に疑問を持ったからです。特定のサイトのあり方に難癖をつける気はないのですが、たとえば多くの方が利用している「mixi」を考えてみてください。日記を書き込むとき、いったん内容確認の画面に移り、ここで「作成する」をクリックすると日記が書き込まれます。このとき原則として、ユーザーは他の作業を行うことはできません。画面には他にもリンクが表示されていますが「作成する」「戻る」以外のリンクをクリックすると、入力した内容が破棄されます。つまりアプリケーションの処理ステップ毎にモードが切り替わり、そのモード毎に行える処理内容が変わってしまうのです。

ユーザー登録などでユーザー情報を入力する画面でも、モーダル型のものは少なくありません。あるいはログイン画面などもそうです。ログインボタンをクリックすると、画面全体がログイン画面に遷移し、ログイン処理が終わるとトップ画面に遷移する、といった感じです。

このように、特定機能毎に画面が定義され、ユーザー操作によってどんどん画面全体が遷移するアプリケーションを見ると、私はまるで「ホスト時代の再来」のような感じがします。あるいはDOS全盛期にも、モーダル型のアプリケーションが数多くありました。しかしGUIが一般的になるにつれて、モーダル型のアプリケーションはどんどん少なくなり、いまでは処理内容によって画面全体が遷移するようなアプリケーションは、むしろ珍しい存在になっています。例えばExcelを考えてください。セルにデータを入力する時「入力画面」に切り替わる、なんてことはありませんよね。常にワークシートが表示された状態で、ユーザーはさまざまな操作を行えます。これが非モーダルな環境です。

画面遷移が頻繁に発生するアプリケーションでは、ユーザーはしばしば自分の「立ち位置」を見失います。画面遷移はユーザーに「アプリケーション内での移動」を感じさせ、しかもその移動が相手によって強制的に行われたように感じます。これに対して非モーダルなアプリケーションでは、ユーザーは常に同じ立ち位置にいながら、多様な操作を行えます。モーダルなものより非モーダルなものの方が使いやすい、というのは、すでに多くの実例によって明らかになっています。だからこそデスクトップアプリケーションは、非モーダルな環境を目指し続けてきたわけです。

Webアプリケーションがモーダル型になってしまうのは、ステートレスという特性を考えれば、やむを得ない選択だったのかも知れません。しかし現在ではセッションを使うことで、ステートフルなWebアプリケーションを作成することもできます。デスクトップアプリケーションと同じように、非モーダルなWebアプリケーションを作成することも、不可能ではないはずです。

しかし実際に非モーダルなWebアプリケーションを作成しようとすると、大きな壁にぶつかります。非モーダルなWebアプリケーションを作成するには、ひとつの画面に複数の機能要素を盛り込む必要があります。つまり画面全体の情報量や機能量が多くなり、アプリケーションの作成やメンテナンスに手間がかかるようになるのです。


理由2:開発生産性の壁

それではこの手間を、いかにして削減するか。これが第2の理由です。

実は私はPHPを使い始めてから、コーディングスタイルを何度か変更しています。その目的は、複数のビューコンポーネントで構成されるWebアプリケーションの開発生産性を高めることです。

まず最初はHTMLとPHPコードが混在している状態からスタートしました。メンテナンス性の観点から言えば、最も悪いスタイルです。その後HTMLとPHPコードの分離(HTML生成部分を関数にまとめることでテンプレート化)し、さらにHTMLに渡す表示データ生成関数をビューコンポーネント毎に作成し、メインプログラムから分離するといったスタイルへと移行しました。しかし構造化プログラミングの発想だけでは、なかなか「切れのいいコンポーネントの分離」ができません。一部のコンポーネントを変更すると、どうしても他のコンポーネントや、メインプログラムでの変更が生じてしまうのです。

たとえばブラウザからのリクエストが発生した時に、以前のフォーム内容を保持したいというケースを考えてみましょう。<input type="hidden">タグで値を保持する方法もありますが、現在ではSESSION変数に待避する方法が一般的です。そのためにはSESSION変数にアクセスするコードが、保持すべきフォームの名前を知らなければなりません。新たなフォームを追加すれば、当然ながらこの部分にもコード変更が生じます。

また<a>タグのリンクをJavaScriptでサブミットボタンとして使いたい場合、どこかで<input type="hidden"...>を記述する必要がありますが、これもビューコンポーネントが変更されれば、画面全体で意識して記述変更する必要があります。このように、仕様変更のたびに複数箇所のコードに触る必要があり、常に画面全体を視野に入れておかないと、バグが発生するという状況になっていたわけです。

このような状況は、仕様変更に対する消極的な姿勢を生みます。いったん動いたアプリケーションには、もう手を付けたくなくなるのです。しかしそれ以上に怖いのは、セキュリティ面での脆弱性ももたらすことです。

Webアプリケーションでセキュリティを確保するには、最低でも「リクエストデータのフィルタリング」「HTML出力時のサニタイズ」「データベース格納時のサニタイズ」が必要です。これらの機能の抜けを回避するには、できるだけ特定の場所にまとめてしまうのが効果的です。しかし構造化プログラミングでは、これも簡単ではありません。


既存のフレームワークではだめだったのか

そこで考えたのがフレームワークの活用です。とりあえず「symfony」と「Zend Framework」の書籍を購入して読み始めたのですが、いまひとつピンと来ませんでした。

多くのフレームワークには「CRUD」と呼ばれる概念があります。「Create」「Read」「Update」「Delete」の頭文字をとったものですが、PHPフレームワークではこれらの処理を、個別のURLに割り当てるのが一般的なアプローチになっています。これはすなわち、各機能を異なる画面に割り当て、求められる機能によって画面遷移を発生させるという発想です。はじめから「モーダル型」でアプリケーションを作成することが、前提になっているように見えたのです。

ひょっとしたらスタディが十分ではなかったのかも知れません。しかしサンプルコードを見る限り、複数の画面構成要素で構成される複雑なWebアプリケーションを、画面構成要素毎に分割して管理する、という感じではないという印象を受けました。

前述のような「非モーダル」なWebアプリケーションを、高い生産性で実現するには、他のアプローチが必要ではないか。このように考えた結果、「PnF」を作ることにしたわけです。
スポンサーサイト

ベンチャーブログのランキングに参加しています。
下のバナーをクリックして応援していただけると嬉しいです。
にほんブログ村 ベンチャーブログへ

FC2Ad

相続 会社設立

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。