PRADO:イベントドリブン型PHPフレームワーク ぎじゅっやさん

実はもうSymfony使ってません。(早!

(ノ・・)ン。。。。。。(((●コロコロッ

Ruby on Rails全盛で、
PHPのフレームワークもすっかりRails一色になってきている。
それはそれで良いのだが、
未だRuby on Railsが好きになれないので、
いろいろ調査だけは続けている。
ＭＶＣってのは幻想だな。
Symfonyでおおよそ固めてはいたが、
他に良いのがあれば速攻で乗換・・・良いの発見！！

それは
PRADO

[More:]

PRADOとは？

PRADOTM is a component-based and event-driven programming framework for developing Web applications in PHP 5.
Main Features of PRADO

• Object-oriented and highly reusable code
• Event-driven programming
• Separation of presentation and logic
• Configurable and pluggable modular architecture
• Feature-rich Web components: HTML input controls, validators, datagrid, wizard...
• Built-in support of internationalization (I18N) and localization (L10N)
• Seamless Ajax support
• Customizable and localizable error/exception handling
• Multiway message logging with filters
• Generic caching modules and selective output caching
• Extensible authentication and authorization framework
• Security measures: cross-site script (XSS) prevention, cookie protection...
• XHTML compliance
• Rich documentation and strong userbase

イベント駆動型のPHPフレームワーク。
拡張性、再利用性に非常に優れていて、
OOPで再利用性を高めたつもりでいた私には度肝を抜かれた。
また、ロジックとプレゼンテーション部分が完全に分かれているので、
メンテナンス性も非常に高い。
テンプレートにプログラミングしてしまうMVC幻想とは違うな。
利用できるコンポーネントの数が半端じゃなく、
良く作ったなぁと感心してしまう。


ここにまとめていくことにしよう。
PRADO [dozo dokuwiki.php]

特筆するのはやはりWizardコンポーネントだろう。
一枚のページにWizardStepという区切りを設け、
ページの遷移をStepごとに作っていく。
例えば、

<com:TWizard ID="hoge">
<com:TWizardStep ID="input">
<!-- 入力画面 -->
</com:TWizardStep>
<com:TWizardStep ID="confirm">
<!-- 確認画面 -->
</com:TWizardStep>
<com:TWizardStep ID="complete" StepType="Complete">
<!-- 完了画面 -->
</com:TWizardStep>
</com:TWizard>

これだけで「next」「previous」「complete」ボタンの付いた画面遷移が出来上がる。
パラメータも非常に多くロジック連携も出来るので、
途中で分岐するような複雑な画面遷移も簡単に出来る。

あとviewstateという概念も素晴らしい。
通常PHPアプリのデータ保存場所は、
セッションかCookieだが、
第３の概念としてViewStateというのが追加されている。
実体はどちらかというとCookieに近いクライアントサイドの保存場所。
AJAXで確保しにくいストレージを実現できる上、
先のWizardもこれがあって初めて動作している。
(といいつつ動作原理が未だわかっていない。)

データベースマッピングのSqlMapも良い。
iBatisを参考にしている(Apacheファン？)ようで、
キチンとSQLが組める上、
DBスキーマとの連携も取りやすい。
結果セットにスキーマクラスがセットできるので、
データの変更も簡単。
(他のフレームワークでもこれを使いたいのだがどうにかならないかな。)
一応Active Recordも存在する。
使い勝手はアクティブ･レコードの方が良いのだが、
世にあるActive Recordと同じで、
クエリ数多いわ、ＳＱＬがわけわからんわと使い物にならない。



ASP.netやDelphiをかなり参考にしているようで、
「プログラミングしている」という感覚はほとんど無い。
どちらかというとHTML書いている感覚に近い。
ロジックを全く書かなくてもページが出来上がる事が多い。
よくよく考えると画面遷移を「プログラミング」するのはナンセンスだな。
IDEとの連携がもっとよくなるといいなぁ。

ドキュメントもかなりしっかりしていて、
逆に探すのが大変という状態。
サンプルをもっと増やすといいかも。
まぁ、それはオレがやればいいのか。

イベント駆動型という仕組み上、
AJAXとの連携が取りやすい。
onClick時の動作をAjaxあり・なしで選ぶ感じ。




もちろんデメリットもある。
最たるところはプレゼンテーション(テンプレート)の可読性と動作速度。

プレゼンテーションには独自タグをガンガン埋め込んでいくので、
Flexy使い(最近はPHPTAL)としては可読性維持の方法を模索したいところだが、
システムの仕様上無理かもしれない。
ただ、出来上がるプレゼンテーションは完全なXMLは維持している。
Smartyの様に酷くなったりはしない。
タグも「com:THyperLink」など内容がわかる名称となっている。
今のところ読めなくなったりはしていない。


動作速度はかなり犠牲にしているだろうな。
実測値は取っていないが。
たぶん、コンポーネントを使えば使うほど遅くなると思う。
PVの多いページでは極力コンポーネント利用を抑えるとか、
キャッシュをフル活用するなどの工夫が必要かもしれない。
(関係ないけど、最近のフレームワークの動作速度を比較した記事のおかげでCodeIgniterが注目されているのが面白い。
２年ぐらい使ってる私としては今頃感満載。)


さて、問題は私がケータイ屋さんであることで、
ケータイで利用できない場合はどんなに素晴らしいものでも没にせざるを得ない。
どこまでやれるかお試し中。
拡張性が高いので、
ケータイで問題になりそうな「絵文字」「SJIS」「Softbank」「製造番号認証(かんたんログイン)」などは今のところ問題なく処理できている。
「vodafoneC型」だけはFormのaction属性にクエリストリングが入るので無理かもしれない。
(っていうか非対応端末でいいけどね。)

バリデータがＣＳＳのvisibliltyやdisableでエラーメッセージを表示・非表示にする仕組みになっている。
ケータイでは垂れ流し表示になってしまうのと、
仕様自体かなり気に入らないのでそこは抹殺する様に拡張した。
ただし、フレームワークには全く手を入れていない。
今のところEthnaの様にフレームワークガンガンHACKということにはなってない。

このあたりにまとめていこう。




これを見ていると「プログラミング」っていうのも、
どんどん必要無くなっていくのかなぁと思ってしまう。