Djangoプログラマから見たCatalyst, Symfonyの良いところ - スコトプリゴニエフスク通信
最近、自分でCatalystで遊んだり、自分の周りで「空前のSymfonyブーム」が起きている？？関係で、非PythonのWebフレームワークを触っています。備忘録がわりに、Catalyst, Symfonyがよいと思った点をメモしておきます。CatalystCatalystを完全に理解したとは言えないが・・・ 何かあるテンプレートエンジンやORMを前提としない点がよい。 URLルーティングシステムは、Djangoよりも簡潔かつ、Djangoと同じくらい強力に見える。 stashという概念は扱い易い。 flash変数という概念は非常に便利。なぜDjangoにないのかが疑問。 redirectではなく、forwardができるのはDjangoより遥かに便利。なぜDjangoにないのかが疑問。Symfony テストの部分がちゃんとしている。テスト実行前にYAMLで書いたFIxtureを読み込んで
Webフレームワークを考える - Daio Today
Webフレームワークを考える 半年ぐらい前からPerlでWebアプリケーションを作るフレームワークを作りたいと思っていて、あーでもないこーでもないとちょこちょこ考えたりしていたが、最近目にした２つの“事例”を参考にさせて頂いて、自分なりのモデルを考えてみた。 まず、「Perl の MVC フレームワーク Catalyst に入門してみた : NDO::Weblog」から読み取れた Catalyst の構造。 Catalyst は規模が大きいので習得するヒマがなかったのだが、この記事を見て大筋で理解した（事にした）。 Catalystモデルのメリットは（モデルの）シンプルさにあり、簡単なアプリをサクッと作るにはよさそう。 しかし、Controller への依存度が高過ぎるため、コードのメンテナンス性が低くなりそうな懸念がある。 また、実際の Catalyst はフレームワークの完成度が高い
Catalyst, Sledge, Maypole - libnitsuji.so
どれもPerlのフレームワークです。 Maypoleのソースを読んで、少し模写して、なんとなく流れがわかってきたところで、他のフレームワークがどうなってるのか気になってきました。で、すぐに思いつくところとしてCatalystとSledgeのソースを読んでみました。といっても、（これにはすごく驚いたのだけれど）Catalystは巨大すぎてとてもソースを読んでいられなかったので、ほぼすべてマニュアルから知識を仕入れました。どれもちゃんと使ったことはないので、とんちんかんな理解かもしれないけれど、とりあえずメモっておこう。 Maypole 3つの中では一番お固いフレームワーク。固いってのは、フレームワーク側が処理フローの多くを決めてしまうのでアプリケーション側でやること（できること）が少ないってことです。そのぶん、うまくいけば簡単にアプリケーションを作れます（たぶん）。MaypoleのキホンはU
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
