6

カプチーノについて頭を悩ませようとしています。StackOverview の仲間に、以下のアーキテクチャをレビューして、それが理にかなっているかどうかを確認してもらいたいと思います.Django と Cappuccino のユニークな利点を、テクノロジーが重複する場所で二重にすることなく活用することを目的としています...

Web ブラウザーが「わかりやすい」URL (例: /、/articles など) を要求する場合:

  • DJango の urls.py は、これをビューに一致させます。
  • このビューは、DJangos がローカルの辞書をテンプレートに入力する典型的な作業を行うのではなく
    、カプチーノ アプリで使用される小さな「スタブ」HTML を直接返します。
  • クライアントはカプチーノ HTML を受け取ります
  • クライアントは、スタブ HTML に記載されている Objective J JS URL を要求します。
  • エンドユーザー アプリが実行され、ブラウザーに表示される

ブラウザには動作するアプリがあります。ユーザーがサーバーから何かを要求する何かを行う場合:

  • ブラウザは XMLHTTPRequest を URL に送信します。
  • Django の URLs.py は、これをビューに一致させます。
  • ビューは機能し、おそらく DB モデルとやり取りします。ただし、テンプレートを返す代わりに、Django は JSON を返します。
  • クライアントは JSON を受け取り、必要なことは何でも行います。

これは理にかなっていますか？わかりやすい URL と、コードをモデル化するためのデータベースが作成されているという利点はまだあります。ただし、テンプレートを使用するのではなく、Cappuccino のスタブ ページと JSON 応答を提供して、ユーザーに実際のアプリのようなものを提供し、HTML テンプレート エンジンのようなものを提供しません。

おそらく物事を行うためのより良い方法はありますか？他の Pythonista は何を使っていますか? ご意見をいただきありがとうございます。

4

1 に答える 1

4

トラフィックの少ないサイトの場合、Djangoのルーティングレイヤーを使用することは問題ありませんが、大量のトラフィックを取得する予定の場合は、プロキシWebサーバーにスタブを処理させることを検討してください。

残りの部分については、それは機能し、TurboGearsコミュニティは何年もそれを行ってきました（私はTGコミッターだったので、それが私が通常使用しているものです）。辞書をテンプレートに返すTGアーキテクチャでは、テンプレートエンジンとして「json」を設定するだけなので、これは簡単です。

Djangoで同じことを行うことは、それほど複雑ではありません。テンプレート呼び出しを使用するのではなく、シリアル化ツールを使用して結果を応答に書き込むだけです。

このようなアーキテクチャを実行する場合、すべてのアプリケーションロジックを1つの場所に保持すると、管理がかなり簡単になることに注意してください。一部のアプリロジックをDjangoに配置し、一部をブラウザーに配置すると、物事がかなり早く乱雑になり始めます。サーバーを（検証/認証/承認を除いて）ダム永続層として扱うと、作業が楽になります。

FWIW、より重い非プログレッシブエンハンスメントフレームワークに興味がある場合は、カプチーノよりもSproutcoreの方が扱いやすいと思います。

于 2009-10-25T19:06:33.683 に答える