| Home |
2007.06.03 論理プログラミングと、Webアプリケーション
現状、Webアプリケーションは PHP や Java、Perl、あるいは Microsoft の ASP などで記述される事がほとんどだと思います。
これらの言語はすべて手続き型のパラダイムを根底に持っていますが、
Web アプリケーションの処理の制御時には、
論理プログラミングのパラダイムを利用すると良いのではないかと
考えています。
Blogランキング参加しています
基本的なWebアプリケーションである、メール送信フォームを
考えてみます。
画面は3つあります。
・データ入力フォーム表示
・確認画面表示
・メール送信完了画面表示
正常な使用のみを考えた場合は、
確認画面へ遷移する際:
入力チェックを行う
○ → 確認画面表示
× → データ入力フォーム表示
完了画面へ遷移する際:
メール送信
のみですみます。擬似ソースにすると(リストA)のようになります:
ただし、情報の保持にHIDDENを用いた際に情報の改ざん等を
考慮した場合は完了画面へ遷移(とメール送信)する際にも
入力チェックが必要になります(リストB):
現在は、画面が2画面ですが、
もっと多量のデータを入力する場合は画面がさらに増え、
それに応じて各対応動作の際にチェックが必要になります。
上記の処理の重複を取り除くようにコーディングすると、
のようになります。
最初のソースコード(リストA)はシンプルでしたが、
値チェックを回避するルートが存在します。
後者のソースコード(リストC)は値チェックを回避する
ルートは存在しませんが、ソースは経験上、次第にネストが
深くなる傾向がありあす。
関数やメソッドなどの構造で共通化を行ったとしてもはたして、
いつまで耐えられるでしょうか。さらに、戻る処理などもあります。
両者の利点を生かし、欠点をなくす、すなわちソースを
シンプルに保ったまま、不正なパラメータに堅牢な(Web)アプリケーション
の構築に論理プログラミングを適用する事を考えています。
論理プログラミングで有名なものは Prolog ですが、
その他にも、make や ant といった、ビルドツールにも
そのパラダイムを見ることができます。
(注: この記述は個人的な感覚であり、裏付けする情報は何もありません)
たとえば、ビルドツールの make を例にとってみます。
test.exe という実行ファイルを生成するのに、
test.obj というオブジェクトファイルが必要で、test.obj は
test.c をコンパイルすると生成される、
といった状況をあらわす Makefile は VC++を利用する場合には
のようになります。上記のMakefileではファイルの有無や
更新日付を見て適宜コマンドが実行されます。
test.c しかない場合に nmake を起動した際、実行されるコマンドは:
cl /c test.c
link test.obj
test.obj がある場合に実行されるコマンドは:
link test.obj
メールフォームの画面遷移と、上記の nmake の動作には何か
通じるところがあると感じています。
たとえば、以下のような宣言を行うことで、
完了画面表示: メール送信
メール送信: 確認済み
mail(param('email'))
確認済み: 確認
param('confirm') == true
確認: 正しいデータ入力
required('name', 'email')
valid_address('email')
(リストC)に相当する動作が実現するとしたら、ソースもきれいで、
堅牢な動作をする、ということも可能になると考えています。
このような例を実装したものは見たことがありませんが、
各種Webフレームワークにおいて、認証の仕組みに似たものは感じます。
Struts Workflow Extension が少し近い気もしています。
http://www.livinglogic.de/Struts/
メールフォームは画面が3つありますが、妥当なデータと、
確認済みである、という情報を送信すれば、いきなりメールを
送信して、完了画面を出すことも可能です。
確認済みでも、データは不正だったら、入力画面を表示するという
動きになります。
ただ、最近ではこのような動作ができることを悪用するケースも
ありますが…。
written:Takumi
Blogランキング参加しています
考えてみます。
画面は3つあります。
・データ入力フォーム表示
・確認画面表示
・メール送信完了画面表示
正常な使用のみを考えた場合は、
確認画面へ遷移する際:
入力チェックを行う
○ → 確認画面表示
× → データ入力フォーム表示
完了画面へ遷移する際:
メール送信
のみですみます。擬似ソースにすると(リストA)のようになります:
if (確認ボタンが押された) {
if (エラーチェック = OK) {
確認画面表示
} else {
入力画面表示
}
} elsif (送信ボタンが押された) {
メール送信
完了画面表示
} else {
初期表示
}
(リストA)ただし、情報の保持にHIDDENを用いた際に情報の改ざん等を
考慮した場合は完了画面へ遷移(とメール送信)する際にも
入力チェックが必要になります(リストB):
if (確認ボタンが押された) {
if (エラーチェック = OK) {
確認画面表示
} else {
入力画面表示
}
} elsif (送信ボタンが押された) {
if (エラーチェック = OK) {
メール送信
完了画面表示
} else {
不正な状態
}
} else {
初期表示
}
(リストB)現在は、画面が2画面ですが、
もっと多量のデータを入力する場合は画面がさらに増え、
それに応じて各対応動作の際にチェックが必要になります。
上記の処理の重複を取り除くようにコーディングすると、
if (なんらかの入力がなされた) {
if (エラーチェック = OK) {
if (確認済み) {
メール送信
完了画面表示
} else {
確認画面表示
}
} else {
入力画面表示
}
} else {
初期表示
}
(リストC)のようになります。
最初のソースコード(リストA)はシンプルでしたが、
値チェックを回避するルートが存在します。
後者のソースコード(リストC)は値チェックを回避する
ルートは存在しませんが、ソースは経験上、次第にネストが
深くなる傾向がありあす。
関数やメソッドなどの構造で共通化を行ったとしてもはたして、
いつまで耐えられるでしょうか。さらに、戻る処理などもあります。
両者の利点を生かし、欠点をなくす、すなわちソースを
シンプルに保ったまま、不正なパラメータに堅牢な(Web)アプリケーション
の構築に論理プログラミングを適用する事を考えています。
論理プログラミングで有名なものは Prolog ですが、
その他にも、make や ant といった、ビルドツールにも
そのパラダイムを見ることができます。
(注: この記述は個人的な感覚であり、裏付けする情報は何もありません)
たとえば、ビルドツールの make を例にとってみます。
test.exe という実行ファイルを生成するのに、
test.obj というオブジェクトファイルが必要で、test.obj は
test.c をコンパイルすると生成される、
といった状況をあらわす Makefile は VC++を利用する場合には
test.exe: test.obj
link test.obj
test.obj: test.c
cl /c test.c
のようになります。上記のMakefileではファイルの有無や
更新日付を見て適宜コマンドが実行されます。
test.c しかない場合に nmake を起動した際、実行されるコマンドは:
cl /c test.c
link test.obj
test.obj がある場合に実行されるコマンドは:
link test.obj
メールフォームの画面遷移と、上記の nmake の動作には何か
通じるところがあると感じています。
たとえば、以下のような宣言を行うことで、
完了画面表示: メール送信
メール送信: 確認済み
mail(param('email'))
確認済み: 確認
param('confirm') == true
確認: 正しいデータ入力
required('name', 'email')
valid_address('email')
(リストC)に相当する動作が実現するとしたら、ソースもきれいで、
堅牢な動作をする、ということも可能になると考えています。
このような例を実装したものは見たことがありませんが、
各種Webフレームワークにおいて、認証の仕組みに似たものは感じます。
Struts Workflow Extension が少し近い気もしています。
http://www.livinglogic.de/Struts/
メールフォームは画面が3つありますが、妥当なデータと、
確認済みである、という情報を送信すれば、いきなりメールを
送信して、完了画面を出すことも可能です。
確認済みでも、データは不正だったら、入力画面を表示するという
動きになります。
ただ、最近ではこのような動作ができることを悪用するケースも
ありますが…。
written:Takumi
Blogランキング参加しています
| Home |










