カテゴリー

最新の記事

最近のコメント

最近のトラックバック

月別アーカイブ

ブログ検索

RSSフィード

ブロとも申請フォーム

この人とブロともになる

スポンサーサイト

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

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

PHPフレームワークもどき「PnF」(5)~サンプルコード「MenuBox」

PHP
2008.11.24
それではサンプルアプリケーションのコードを作成してみます。まずは「MenuBox」のコードからです。ビューコンポーネントのコードの実態は「ひとつのクラス定義」なのですが、ここではいくつかの部分に分けて説明したいと思います。
なおここからは、ビューコンポーネントをVC、ビューパーツをVPと記述します。

まずは前半部分から。

コード5-1

3行目
親クラスの定義をインクルードしています。ビューコンポーネントに必要な処理のほとんどは親クラスに実装されています。「VIEWCOMPONENT_DIR」はこの親クラスが格納されているディレクトリパスを示しており、config.phpの中で定義されています。

5行目
親クラス「ViewComponent」から「VcMenuBox」を派生させています。クラス名はなんでもいいのですが、頭に「Vc」を付けることをルールにしています。また他のVCクラス名と名前がバッティングしないことも必要です。

14~15行目
このVCに固有のプロパティの定義です。VCが保持する必要がある情報を格納します。MenuBoxにはそのような情報は特にないので、ここは空配列を記述します。

17~38行目
このVCが使用するVPを宣言しています。宣言の記述方法は、各VP名をキーとする連想配列の形で行います。各連想配列の値は、VPのプロパティを格納した構造体です。
ここでは操作メニューのリストを「Menu」という名前のVPとして宣言しています。VPの内容は「VpMenuList」というクラスで定義されています。「VpMenuList」というクラスは、<a>タグで記述されたリンクにJavaScriptでサブミット機能を与えたものを、複数定義できるというものです。各項目の意味は以下の通りです。

 'class_name' :VPを定義しているクラス名です。
 'data_type'  :このVPがどのようなPOST変数を受け取るのか。
         この定義によってフィルタリングを行います。
 'menu_list'  :各メニューのデータです。
         以下の組み合わせを複数設定できます。

  'value'   :メニューがクリックされた時のPOST変数の値。
  'text'    :メニューに表示される文字列。
  'href'    :JavaScriptが無効である場合のリンク先。

ここでは「アイテムを追加」「リストをクリア」という、ふたつのメニュー項目を定義しています。なお'value'で定義した文字列は、メニューがクリックされた時に、このVCに対して「ローカルイベント」として引き渡されます。ローカルイベントとは、自分自身だけにパブリッシュされるイベントのことです。他にグローバル、アウトサイドという2種類のパブリッシュ方法がありますが、VPが直接発生させるイベントは、すべてそのVPを使用しているVCのローカルイベントになります。
ちなみに「VpMenuList」の内容は以下の通りです。

コード5-2-1
コード5-2-2


ちょっとコメントが長いのですが、実際のコードはそれほど長くないのがおわかりいただけると思います。VPのコードの詳細については別の機会に説明します。

40~41行目
このVCで処理を引き受けるGET変数を定義します。ここでは何も引き受けないので空配列を記述します。

43~58行目
イベントとアクションメソッドの対応を定義しています。ここに記述されたイベントだけが、このVCによってサブスクライブされます。ここでは、先ほどのVPで定義された「OPEN_ENTRY_FORM」と「CLEAR_LIST」が定義され、アクションメソッドと結びつけられています。また「REFRESH」というのはすべてのVCで発生したすべてのイベント処理が終わった後に、PnFコアが自動的に発生させるイベントです。これを捕捉することで画面表示直前に行いたい処理を実行できます。画面表示要素を最終的にリフレッシュする場合に使われるだろうという想定で「REFRESH」という名前にしてあります。

次に後半部分です。

コード5-3

65~66行目
イベント処理チェーンに入る直前に実行したい処理を「前処理」として記述します。このVCでは何も行いません。

68~71行目
イベント/アクションメソッドの対応で定義された「openAddForm」の処理内容です。openAddFormは「FormBox」を表示させるためのメソッドですが、外部のVCに直接アクセスすることは許されません。VC間のやり取りの基本は、イベントを発生させ、それを捕捉してもらう、という手続きになります。
ここではローカルイベントとして捕捉した「OPEN_ENTRY_FORM」を「setEvent」というメソッド(PnFコアで定義されています)で、再びパブリッシュしています。自分自身にこのイベントがやってくると無限ループになるため、イベントタイプは「OUTSIDE」にしています。これは自分以外のVCにイベントをパブリッシュする、という設定です。またイベントパブリッシュの時にはデータを引き渡すこともできます。ここでは引き渡すべきデータがないので「''」としています。
なお第1引数にある「$this->getVcName()」というのは、自分自身の名前(VC名、ここでは「MenuBox」)を取得するためのメソッドです。これはデバッグ用に用意された引数です。(デバッグ機能については別の機会に説明します)

73~76行目
同じく「clearList」の処理内容です。目的は「ItemListBox」の内容のクリアですが、ここでもイベントを外部に再伝達する形になっています。

78~79行目
REFRESHイベントに対応した処理の記述です。ここでは何も行いません。

84~103行目
このVCが最終的に表示する、HTMLのテンプレートです。パブリックなメソッドとして定義されており、VCが表示するHTMLの内容が文字列として返されます。基本的にはPnFコアから呼び出されますが、VCが他のVCを配下に持った場合には、上位のVCのHTMLテンプレートから呼び出されることになります。
VCが使用しているVPにも、HTMLテンプレート関数があります。VCがVPを表示要素にする場合には、VPのHTMLテンプレートを呼び出すことになります。これを可能にするのが「getVpViewData」メソッドです。これはVCの親クラスで定義されているので、頭に「$this->」を付けて呼び出します。引数はVP名とイテレータです。イテレータは複数要素を持つVPから、特定要素に関するタグのみを取り出すために用意したのですが、現在のPnFでは使用されていません。ここでもNULLを渡しています。

このようにVCの作成は、いくつかの定義(宣言)と、アクションメソッドの記述、HTMLテンプレートの記述で構成されます。つまり「最初にMVCを分けてしまう」のではなく、「まずビューコンポーネント毎にブロックを分けて、その中でControlとViewを分け、必要に応じてControlからModelを呼び出す」というイメージです。イベント名の整合性は必要ですが、それ以外は他のVCの存在を意識する必要はありません。これによって開発時に「視野に入れるべきエリア」を最小化できるわけです。

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

PHPフレームワークもどき「PnF」(4)~PnFの開発スタイル

PHP
2008.11.24
それでは前回のサンプルアプリを、PnF上で構築したいと思います。まずPnFを使った開発の基本的な考え方を説明しておきましょう。

基本的な考え方

PnFによるWebアプリケーション開発は、以下の4つの部分に分けてアプローチします。

(1)画面全体の構成
(2)画面を構成するビューコンポーネント(VC)
(3)ビューコンポーネントで使用するビューパーツ(VP)
(4)データモデルオブジェクト(DM)

これらの要素を「PnFコア」で結びつけたものが、PnFで作成したWebアプリケーションになります。

図4-1
(クリックすると拡大表示されます)

ビューコンポーネントとは、ひとまとまりの機能を提供する表示ブロックのことです。例えば前回のサンプルアプリでは、メニューを表示するボックス、フォームを表示するボックス、アイテムのリストを表示するボックス、各アイテムの情報を表示するボックスが、ビューコンポーネントとして記述されています。

ビューパーツは単一機能を提供する部品だとお考えください。例えばテキスト入力フィールドやテキストエリア入力フィールドは、それぞれひとつのビューパーツとして定義されます。また複数要素をもっている場合でも、機能としては単一であれば、ビューパーツの中に含めるべきだと考えています。例えばメニューリストやフォームのナビゲーションリンク等は、それぞれ複数の要素を持ちますが、基本的な機能は単一なので、それぞれビューパーツとして定義しています。

ここでポイントになるのは、ビューパーツの種類は限られていること、そして限られた種類のビューパーツを事前に作成しておけばアプリケーション開発者はそれを利用するだけでいいということです。つまりアプリケーション開発者は、基本的に(1)(2)(4)を視野に入れればいいことになります。もちろんビューパーツを追加することもできます。コード解説のところで述べますが、それぞれのビューパーツの記述はかなり短いものです。また(1)の画面全体の構成の記述もかなり短く、アプリ開発者は「使用するビューコンポーネント」と「そのビューコンポーネントを画面の中でどのように配置するか(HTMLテンプレート)」のみを意識すればOKです。

これに対してビューコンポーネントの記述は、PnFにおける開発の「キモ」といえる部分です。ビューコンポーネントの記述には、「ビューコンポーネントのプロパティ定義」「使用するビューパーツの定義」「このコンポーネントが担当するGET変数の定義」「イベントハンドリングの定義」「各イベントに対応したアクションメソッドの記述」「HTMLテンプレート」が含まれます。

POST変数の処理はビューパーツが担当します。一般的なWebアプリケーションの場合、POST変数は特定のHTMLタグに結びつけることが可能だからです。HTMLタグを直接記述するのはビューパーツなので、ここに処理を任せているのです。(とはいっても、具体的な処理内容は各ビューパーツの親クラスで行われており、その内容は各ビューパーツからは隠蔽されています。)


開発のアプローチ

前回のサンプルアプリケーションを作成する場合には、次のようにアプローチしていきます。

Step1:必要なビューコンポーネントを洗い出す。
前回のサンプルアプリケーションの場合、ビューコンポーネントは「メニューボックス(MenuBox)」「データ登録フォームボックス(FormBox)」「アイテムリストの表示ボックス(ItemListBox)」「各アイテムの表示ボックス(ItemBox)」に分けられそうです。また「ItemBox」は「ItemListBox」の下位コンポーネントにすると、全体がすっきりしそうです。

図4-2

Step2:各ビューコンポーネントが保持すべき情報を洗い出す。
例えば「ItemListBox」では、登録されたデータの内容と、登録されたデータ数をSESSION変数で保持しておく必要がありそうです。また「FormBox」は表示/非表示を切り替えるために、表示モードを保持することが求められます。

Step3:各ビューコンポーネントが使用するビューパーツを洗い出す。
例えば「FormBox」では「テキスト入力フィールド」「メールアドレス入力フィールド」「テキストエリア入力フィールド」「ナビゲーションリンク」を使うことになります。

Step4:対応すべきイベントを洗い出す。
例えば「FormBox」では、「アイテムを追加」のクリック、「登録」のクリック、「キャンセル」のクリックが発生した時に、それぞれ何らかの処理が必要です。

Step5:各イベントに対応したアクションメソッドを定義する。
例えば「ItemBox」の「詳細を表示する」をクリックした時、「ItemBox」は詳細情報の表示を行うと共に、ナビゲーションの表示を「詳細を隠す」に切り替える必要があります。このような動的な処理を、アクションメソッドとして記述します。

あるビューコンポーネントが、他のビューコンポーネントの状態を変えたい時もあります。例えば「FormBox」の「登録」がクリックされた時には、何らかの手段で「ItemListBox」にそのイベントを伝達し、入力されたデータを引き渡す必要があります。この場合、直接他のコンポーネントの状態にアクセスしてしまうと、コンポーネント間が密結合になってしまいます。
そこでPnFではアクションメソッドで再びイベントを発生させ、そのイベントを他のコンポーネントが捕捉、必要な処理を行うという方法を採用しています。これは「Publish/Subscribeモデル」に基づいており、パブリッシュ側は「誰がそのイベントを捕捉するのか」、サブスクライブ側は「誰がそのイベントを発生させたか」を、まったく意識する必要はありません。もちろんどのようなイベント名で何を伝達するのかについては、きちんと取り決めしておく必要があります。

Step6:画面全体の構成を決める。
どのビューコンポーネントを使用するのか、画面全体の構成の中でどこに位置づけるのかを記述します。

なお前述のように、データモデルはアクションメソッドから呼び出す形になりますが、今回はデータベースなどのデータモデルは使用しません。そのためデータモデルの開発は行いません。(現時点ではMySQLにアクセスするための機能を実装しています)

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

PHPフレームワークもどき「PnF」(3)~サンプルアプリを作ってみよう

PHP
2008.11.24
「PnF」は、複数のビューコンポーネントで構成された「非モーダル型」のWebアプリケーションの作成を、容易にするために開発されたものです。しかし理屈をいくら並べても、具体的なイメージはつかみにくいと思います。そこでまず簡単なサンプルアプリケーションをお見せします。そしてその後に、これが「PnF」でどのように開発できるのかを示したいと思います。

ここでサンプルとして取り上げるのは、名簿作成アプリケーションです。まず下の画面をごらんください。

サンプル画面1

このアプリケーションはふたつのカラムで構成されており、左側にメニュー、右側に入力済みの名簿データが表示されるようになっています。まだ「登録されているアイテム数」はゼロです。画面下に表示されている数値は、サーバー内処理の実行時間です。PnFコアが自動的に出力します。

さっそく「アイテム追加」をクリックし、アイテムを追加してみましょう。「アイテム追加」をクリックすると、右側のカラムに入力フォームが表示されます。

サンプル画面2

ここでデータを入力するのですが、「名前」欄と「メールアドレス」欄は、空欄のままではエラーになるように設定されています。試しにそのままの状態で「登録」をクリックしてみます。

サンプル画面3

それぞれのフィールドの上に、エラーメッセージが表示されます。また「メールアドレス」欄は、メールアドレスとしておかしい文字列を入力して「登録」をクリックした場合も、エラーが表示されるようになっています。

サンプル画面4

それではデータの登録を行いましょう。適切なデータを入力して「登録」をクリックすると、「登録されているアイテム数」がインクリメントされ、そのデータのうち「名前」と「メールアドレス」で構成されたリストが表示されます。なおこのサンプルでは「登録」時にフォームデータをクリアしていません。

サンプル画面5

おなじ要領で、いくつかのデータを登録していきます。

サンプル画面6

フォームの「キャンセル」をクリックすると、フォームが消えます。この時フォームの内容がクリアされます。つまり次にフォームを開くときには、まっさらな状態のフォームが出てくるというわけです。

サンプル画面7

これで3人分のデータが登録された名簿ができました。各アイテムは「名前」と「メールアドレス」しか表示されていませんが、「詳細を表示する」をクリックすると、先ほど入力した「詳細」部分のテキストが表示されます。この機能はそれぞれのアイテムで独立して動き、複数アイテムの詳細を同時に表示することも可能です。たとえばこんな感じで。

サンプル画面8

ここでちょっと注目していただきたいのが、「いじわるねずみ」の詳細記述にスクリプトが記述されていることです。しかしPnFコアによってタグがエスケープされているため、タグが文字列として表示されています。

「リストをクリア」をクリックすると、これらのアイテムがすべて削除されます。

サンプル画面9

これでまた最初の状態に戻りました。

このサンプルアプリは、非常に単純なものです。しかし注目すべきポイントがひとつあります。それは「登録」「表示」「削除」を「大きな画面遷移なしで」実行している点です。つまりユーザーは、ひとつの画面で複数の機能を使っているように感じるというわけです。これはユーザビリティを高める上で、非常に重要なポイントだと考えています。もちろん「編集」も、そのための機能を追加すれば、問題なく同じ画面で実装できます。

もちろんこのようなアプリケーションを、PnFを使わずに作成することも可能です。この程度の複雑さであれば、それほど苦労することはないはずです。しかしPnFを利用すれば、ビューコンポーネントの独立性を高めることができるため、アプリケーションの複雑さが増してもコードの複雑さを抑制できます。

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

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」を作ることにしたわけです。

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

PHPフレームワークもどき「PnF」(1)~はじめに

PHP
2008.11.24
PHPでWebアプリケーションを作成している時、コードが思った以上に複雑になり、修正や変更が億劫になった経験はありませんか。特にひとつの画面が複数の機能要素で構成されている場合には、複雑さの管理が厄介ではないでしょうか。

Webアプリケーションでは「画面」がひとつの単位になっており、アプリケーション機能を「画面遷移」で分離することで、複雑さをコントロールできます。しかしユーザビリティを高めるために、ひとつ画面に数多くの機能要素を盛り込みたい場合には、画面遷移による機能分割というアプローチは使えません。それではどうしたらいいのでしょうか。この問いに対する答えとして作成したのが「フレームワークもどきPnF」です。

PnFでは画面全体を複数の構成要素(ビューコンポーネント)に分割し、それぞれを個別に開発できるようにしています。ひとつのビューコンポーネントはひとつのオブジェクト(クラス)として定義され、そのクラスの中でビューとコントロールが分離されています。ビューコンポーネント同士は相互に連携でき、全体としてひとつのアプリケーションを構成できます。これによって画面全体を意識せずに、複雑な構成のWebアプリケーションを開発できるようになるわけです。

PnFはPHPの使用を開始してわずか4ヶ月という、いわば「PHPの素人」が、2週間程度で作成したものです。そのためまだ十分に練れていない部分や、バグが残っている部分、機能的に不足している部分が数多く残っています。しかし私自身が実際に使った感想を言えば、複雑な画面構成のWebアプリケーションの開発生産性やメンテナンス性を、飛躍的に高められるポテンシャルを持っているのではないかと感じています。

PnFを使用したWebアプリケーション開発には、次のようなメリットがあります。

(1)画面構成要素(ビューコンポーネント)毎にコードをまとめ、それらを分離して管理できるため、「分割して統治せよ」の原則を貫きやすくなります。

(2)多くの画面構成要素に共通する機能をPnFのコア部分に実装できるので、バグの発生を抑制しやすくなります。例えばセキュリティ確保のために必要な「POST/GET変数のフィルタリング」はコア部分に実装しています。

(3)継続性のある処理を記述しやすくなります。SESSION変数を使用した変数の保存を、SESSION変数を使っていることをそれほど意識せずに、行えるようにしているからです。

(4)PnF自体がPHPで記述されており、それが実行時に呼び出される構成になっているため、PHPが動く環境さえあれば実装できます。他のランタイム等は必要ありません。なお対応するPHPのバージョンは「5.1.6」です。

Webアプリケーションの複数の機能を「画面遷移で切り替えて」提供する場合には、PnFは必要ないと思います。しかし複数の機能要素をひとつの画面にまとめて提供する場合には、それなりの威力を発揮するはずです。しかし短時間で作成したものなので、まだいろいろな問題が残っているでしょう。またひょっとすると、すでに同様のフレームワークが存在しいるかもしれません。つまり「車輪の再発明」になっている可能性も否定できないのです。

それでも今回このPnFを公開する気になったのは、外部からの評価を受けたいと考えたからです。もし何らかの価値(あるいは価値につながる可能性)があれば、この考え方をさらに押し進めていくかもしれません。逆にこれが「車輪の再発明」または「意味のないこと」だということがわかれば、さっさと手を引くことになるでしょう。

もちろん公開作業にもそれなりの手間がかかるので、何段階かに分けて公開を進めていく計画です。まずは簡単なサンプルアプリケーションを作成し、そのコードがどのように記述されているのかを、このブログ上で紹介します。もしこれに対して何らかの反応があれば、さらに詳しい紹介を行うつもりです。思わしい反応がなければ、公開作業を中断します。

なお「PnF」という名前には、特に大きな意味はありません。「PnF is Not a Framework」の略だと思ってください。GNUの「GNU is Not Unix」みたいですが、PnFの方は「フレームワークに遼か及ばず」といったニュアンスです。最初のPは「パーツ指向」みたいなものだと考えてください。Nを小文字にしたのは「Proprioceptive Neuromuscular Facilitation(固有受容性神経筋促通法)」と混同しないようにするためです。読み方は「ピンフ」ということで。

もし説明内容に疑問が生じた場合には、各エントリーにコメントを付けて、質問してください。助言なども歓迎します。それではよろしくお願いします。

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

FC2Ad

相続 会社設立

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