WebAPIのMVC - yojikのlog
http://naoya.g.hatena.ne.jp/naoya/20060510/1147243094 そこそこジェネリックなViewにModelをプラグインして使うというのは、PluggableMVCに似ていると思った。PluggableMVCの場合はVCペアに関してModelを差し込むわけだけど、イメージは同じ。 5 プラガブルを利用するMVC 今のところ、Smalltalkシステムの中で一番美しいMVCです。ビューとコントローラのペア(VC)は、モデルに関係ない形態になっています。どんなモデルでも、このVCに差し込んで、MVCにするだけで動くようになっています。この差し込んで使うということで「pluggable(プラガブル)」の名前があります。電源プラグ(VC)に、コンセント(M)を差し込むように使えるからです。 どんなModelでもいいとは書いてあるけど、perform: me
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
MVC and Web APIs: blog.bulknews.net
MVC and Web APIs naoyaのはてなダイアリー - MVCフレームワークにおける Web API 実装 Sledge における Web API (XML-RPC/AtomPP) のハンドリングについての言及がありました。これからの MVC フレームワークに求められる必要条件の一つとしてこの Web API を処理しやすいかどうかというのは重要な気がします。 MVC フレームワークと Web APIs (XML-RPC, REST, SOAP) な話。 Catalyst や Sledge なんかの XML-RPC 実装なんかもプラグインででてきていて、Sledge::Plugin::XMLRPC は CPAN から入手できるわけですが（グッジョブ！）、どうも利用者側の実装方法が若干スマートにならない気がしています。 というのは、 use Sledge::Plugin::XML
MVCフレームワークにおける Web API 実装 - naoyaのはてなダイアリー
ちょっと前に 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 を公開するための敷
Ajax時代の、サーバ<->クライアントで協調するMVCフレームワーク：Goodpic
This shop will be powered by Are you the store owner? Log in here
Webフレームワークを考える - Daio Today
Webフレームワークを考える 半年ぐらい前からPerlでWebアプリケーションを作るフレームワークを作りたいと思っていて、あーでもないこーでもないとちょこちょこ考えたりしていたが、最近目にした２つの“事例”を参考にさせて頂いて、自分なりのモデルを考えてみた。 まず、「Perl の MVC フレームワーク Catalyst に入門してみた : NDO::Weblog」から読み取れた Catalyst の構造。 Catalyst は規模が大きいので習得するヒマがなかったのだが、この記事を見て大筋で理解した（事にした）。 Catalystモデルのメリットは（モデルの）シンプルさにあり、簡単なアプリをサクッと作るにはよさそう。 しかし、Controller への依存度が高過ぎるため、コードのメンテナンス性が低くなりそうな懸念がある。 また、実際の Catalyst はフレームワークの完成度が高い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
