ITの世界では、「MVCモデル」というものが知られている。 「MVC」とは、「Model」 「View」 「Controller」の頭文字で、ごく大ざっぱには M (モデル) - データ V (ビュー) - 見せ方 C (コントローラ) - ロジック のような意味だ。これを混ぜてしまうのではなく、別々に切り離す設計にしておくと、うまくいくと言われている。 このMVCの考え方は、ITだけではなく、Webそのものにも適用できそうに思う。 M (モデル) - コンテンツ V (ビュー) - デザイン C (コントローラ) - テクノロジー という感じだ。 かつて、まだブログもなかった頃は、みんな「ホームページ」を作っていた。HTMLを手書きしたり、ツールを使って、ページを1枚1枚作っていた。 この状態では、コンテンツ、デザイン、テクノロジーがごちゃまぜになっている。テキストを書きたいだけだとして
WebアプリケーションフレームワークWicketが正式リリースされたのは2005年の6月。まもなく1年を迎ようとしている。Wicketは、Webアプリケーションの開発を容易にするため、それまでのフレームワークとは一風変わったアプローチを取っていることで注目された。Wicketの現在の最新版はバージョン1.1.1であり、6月には様々な改良が加えられたWicket 1.2がリリースされる予定になっている。本稿では、そのWicketを使用して簡単なWebアプリケーションを作成する方法を紹介する。 Webアプリケーションフレームワーク いわゆるWebブラウザから操作するWebアプリケーションを開発する場合、いちからすべて作成するということはまずない。まず基本となるWebアプリケーションを決め、実現したい機能から必要になるライブラリをそろえ、それらを組み合わせてシステムの開発をおこなう。 Javaを
Java EE(現J2EE)とはJSRとして標準化された多くの技術の集合であり、その組み合わせもまたJSRとして標準化されたものである。JSR 244として策定の進む次期Java EE 5では、EJBのバージョンアップなど多くの話題があるが、新たにJava EE標準として追加されるJSFも注目される。 JSFとはJava-Server-Faces(正式な表記はJava ServerFaces)の頭文字を取ったもので、"faces"とつく名前からも解るように3層のMVC Web開発においてビジュアル層を表現することができる。Sunでは、"JavaServer Faces technology simplifies building user interfaces for JavaServer applications. "(JavaServer Faces Technologyより引用)と表
ちょっと前に miyagawa さんが 12 Things I dislike with Sledge という(数字で始まる Web つーぽいんとおーチックなタイトルで) Sledge の次期バージョンへの要望なんかを書いてます。この中で 10. REST な API や Basic 認証、XML-RPC、Atom などをうまく処理できない と、Sledge における Web API (XML-RPC/AtomPP) のハンドリングについての言及がありました。これからの MVC フレームワークに求められる必要条件の一つとしてこの Web API を処理しやすいかどうかというのは重要な気がします。 フレームワークに Web API 用の API が載っていて、その扱いが容易かつプロトコルの実装を知らなくても使えるようなアーキテクチャになっていると、開発者が Web API を公開するための敷
近年のWebアプリケーション開発は大規模化が進み、基幹システムなどの一角を担うまでになってきています。また、Webアプリケーション開発はレガシーなシステム開発に比べて手間のかかる部分が多いにも関わらず、開発にかけられる工数は短縮化の傾向にあります。 そのため、案件の大規模化で開発に携わる人数も増える傾向にあり、開発チームの各々がWebアプリケーションのライブラリを別々に制作してしまい、同様の機能を持ったライブラリが複数存在してしまったり、またUIを担当するデザイナーとビジネスロジックを担当するプログラマが、いざそれぞれの部分を組み合わせようとしたらうまく機能しなかったりといった様々な問題が出てきます。 このような背景から、それらの問題に対するソリューションのひとつとして現在、開発現場ではWebアプリケーションフレームワークを用いた開発スタイルが注目され、実際に多くの開発会社がWebアプリケ
先日の Shibuya.pm テクニカルトーク #6 で、やっぱり注目のフレームワークは Catalyst なんだなぁーって思いつつ、日頃から Sledge を使っているせいか、あまり良さや真新しさを感じなかったりして。 「メタフレームワーク」という存在定義っぽいので、Catalyst のそれ自体は割と貧相。 なのに Helper まわりとかは妙にゴージャス & 拡張されているので、やる事や Model が決まってればすぐに使え、そうじゃない場合はすぐ使えなさそう。 Rails の対抗馬なのかも知れないですが、Rails な人が wink とか使ってアジャイル開発とか言って見せびらかしているようなのを真似するには向かないかも知れないですね。 まぁ Sledge も Model に制約がなかったりするのでまず向かないですが「10 分でブックマーク作れ」とか言われたら出来るかも知れん。 Cat
一応、先のエントリで、Sledge の API について詳細に解説し、末尾に書いたんですが、miyagawa さんに「最後まで読む奴 1%」とか身も蓋もないことを言われてしまい、まぁたしかにそんな気もするし、折角頑張って 10 分の壁に挑戦したのに注目されていないのも淋しいことこの上茄子だなーと思い、別エントリへ昇格させました。 ということで、Sledge API 解説に続く Sledge 実践編として、10 分で作る Rails アプリ for Windows やら、10 分で作る CakePHP アプリ for Windows あたりにインスパイアされ「10 分で作る Sledge アプリ」というテーマで、無謀にも挑戦してみました。 漢の挑戦をとくとご覧あれ いや、ぶっちゃけ無理っす。 先に結果言いますけど、10 分なんて無理っす。 ちゃんとはかってないですけど、多分 13 分ぐらいか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く