はじめに PerlのWEBアプリケーションフレームワークとして、CGI::Applicationというものがある。 これを使った簡単なアンケートプログラムを紹介する。 プログラムの内容 最初の入力画面で名前などを入力し、確認画面を経て、登録完了画面でデータを登録する。 間違った入力をした場合、確認画面には進まず、入力画面に強制に戻る。 入力画面 （XXXを入力してください） 確認画面 （内容を確認してください） 登録完了画面 （登録完了しました） ファイル構成 index.cgi コントローラー（すべてのユーザリクエストを受ける） config.cfg 設定ファイル tmpl HTMLテンプレートファイルの置き場 input.tmpl 入力画面のHTMLテンプレートファイル check.tmpl 確認画面のHTMLテンプレートファイル finish.tmpl 登録完了画面のHTMLテン
なでしこ開発者のクジラ飛行机です。なんと、来年度（2006年前期）のIPA未踏プロジェクトに採択されました！感涙です！！これで心置きなく、なでしこの開発が継続できます。提案自体は、未踏に採択されることを目標にしていますので、「なでしこ」ではなく、目新しさを狙って「葵（あおい）」という名前で申請しました。なでしこのユーザーが混乱すると思って、ここに、なでしこと、葵（あおい）の関係を、ここに、まとめています。 葵は、WEBアプリケーション開発のためのフレームワークです。開発環境＋実行環境＋ライブラリの３つが実体です。 WEB上で動く、掲示版やゲームなどを、手軽に作ることができます。開発用のMLを使って、開発を盛り上げていきたいと思います。半年と少しの間、ハイペースで開発します。どうぞ、よろしくお願いします。 参考）葵公式ページ なでしこは、IPAの2004年度未踏ユースに採択され開発され
先日の Shibuya.pm テクニカルトーク #6 で、やっぱり注目のフレームワークは Catalyst なんだなぁーって思いつつ、日頃から Sledge を使っているせいか、あまり良さや真新しさを感じなかったりして。 「メタフレームワーク」という存在定義っぽいので、Catalyst のそれ自体は割と貧相。 なのに Helper まわりとかは妙にゴージャス & 拡張されているので、やる事や Model が決まってればすぐに使え、そうじゃない場合はすぐ使えなさそう。 Rails の対抗馬なのかも知れないですが、Rails な人が wink とか使ってアジャイル開発とか言って見せびらかしているようなのを真似するには向かないかも知れないですね。 まぁ Sledge も Model に制約がなかったりするのでまず向かないですが「10 分でブックマーク作れ」とか言われたら出来るかも知れん。 Cat
This shop will be powered by Are you the store owner? Log in here
Web Frameworks explored O'Reilly Network に掲載されてる DHH のインタビュー や LLDN でさらに最近話題になっているなあと感じる Ruby On Rails なわけですが、Rails の数ある特徴の中でも、以下の部分が一番大きなポイントなのかなと。 O'Reilly Network: Ruby on Rails: An Interview with David Heinemeier Hansson ED: What's your favourite Rails feature? DHH: In general, all the things it doesn't do. All the features we said no to. All the ornaments we turned down. All the 20% solutions
Webフレームワークを考える 半年ぐらい前からPerlでWebアプリケーションを作るフレームワークを作りたいと思っていて、あーでもないこーでもないとちょこちょこ考えたりしていたが、最近目にした２つの“事例”を参考にさせて頂いて、自分なりのモデルを考えてみた。 まず、「Perl の MVC フレームワーク Catalyst に入門してみた : NDO::Weblog」から読み取れた Catalyst の構造。 Catalyst は規模が大きいので習得するヒマがなかったのだが、この記事を見て大筋で理解した（事にした）。 Catalystモデルのメリットは（モデルの）シンプルさにあり、簡単なアプリをサクッと作るにはよさそう。 しかし、Controller への依存度が高過ぎるため、コードのメンテナンス性が低くなりそうな懸念がある。 また、実際の Catalyst はフレームワークの完成度が高い
【連載◎開発現場から時代を眺める by arton】第5回 「動的言語と静的言語の交差点──RubyとJava/Seasar2の出会い」 オブジェクト指向言語を利用した開発が当たり前になり，早くもポスト・オブジェクト指向言語は何かという話題も出ているようだが，先日，具体的に今後の技術の一つの方向性を示す話を聞くことができたのでご紹介したいと思う。それは動的なオブジェクト指向言語のRubyと，静的なオブジェクト指向言語のJava，それぞれのフレームワークについての話だったのだが，意外なほど目指している方向性が近いようだ，と確認したということである。 結論を先に書くと，ソフトウエアの動的に決定したい部分を設定ファイルのようにソース・ファイルの外部に置かれる構成要素で解決するのではなく，言語とフレームワークの機能を利用してソース・ファイルの（文字通り）行間を補完することで解決するという方向だ。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
