This shop will be powered by Are you the store owner? Log in here
Ajax時代の、サーバ<->クライアントで協調するMVCフレームワーク：Goodpic
This shop will be powered by Are you the store owner? Log in here
WebのMVC実現の鍵はJavaScriptにあり
前のエントリからの続きなんですが・・・、 HTMLと動的コードの連携ですが、データソースの文字列なりオブジェクトだけサーバサイド生成のJavaScript経由で渡して、すべての動的レンダリング制御をJavaScript + DOMでやるようなフレームワークの方法論って取れないんでしょうか？ って書いてみて、そういえば自分も昔からそういうアプローチで作っているものがありました。UIが高機能で独立性の高いプレーヤー,Viewerのようなものです。 少なくとも今、現在のMVCの理想系は、このアプローチなんじゃないかなと。View = HTMLがスタンドアローンで動くのが一番わかりやすいなら、HTMLはHTMLのままであるべきだとは思うので、bodyのonLoadでせっせと書き換える。そのかわりエンジニアにJavaScript、DOMの知識は必須ね・・・と。 でもベタに作るなら、 prototyp
Jemplate登場によるMVCアーキテクチャ進化の可能性 - Accept Things
2005年はAjaxが流行ました。AjaxによってWebアプリケーションの操作性が劇的によくなりました。しかしその一方で、Ajaxの登場によってWebアプリケーションのアーキテクチャに歪みが生じました。サーバーサイドのコードはMVCアーキテクチャによって綺麗に各層で役割分担ができていますが、クライアントサイドにおいてはそうではありません。現在多くのAjaxベースのアプリケーションでは、JavaScriptコードの中にロジックとHTMLコードを混在させるやり方でAjaxを実現しているため(恐らく)、メンテナンス性の低下を招いています。 そこで今回はこの問題を解決する新たな動きが最近見えてきたので紹介します。そして、新たに登場したJemplateによるMVCアーキテクチャの進化の可能性について考えてみます。 GoodPicの金子さんの予想 以前、GoodPicの金子さんが書かれた以下のエントリ
naoyaのはてなダイアリー - Jemplate で JavaScript でもロジックとビューを分離する
JSON を Template-Toolkit で展開する Jemplate という記事を書いたんですが、Jemplate を使うと何がいいかってのをもう少し詳しく書いてみます。 Jemplate は TT で JavaScript 上の JSON を展開できるんですが、それだけ聞いてもしかすると「これで普段サーバーサイドでやってるテンプレートの展開をクライアントサイドに持って行けて負荷がクライアントに移ってウマー」っていうのが使いどころのようにも思えちゃいますけど、そうじゃない。検索エンジンに引っかからなくなったりとか、アプリケーションの使い勝手が悪くなったりとか色々弊害があります。 そうじゃなくて、Jemplate は JavaScript のためのテンプレートとして使います。 試しに Catalyst で簡単なアプリケーションを作ってみました。ちょっと動かしておく環境がないのでソース
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
