web-dev-qa-db-ja.com

Djangoおよびクライアント側のJavaScriptテンプレート

イントロ

私は現在、非常に標準的なDjangoベースのアプリ(基本的には派手なCRM /連絡先リストのようなもの)を書いています。それは一種の作業ですが、(jQueryを使用して)ますます多くのAJAXy UIコードを使用してインターフェースを改善しようとすると、作業が非常に困難になり始めています。 DOMを解析し、変更をサーバーにプッシュして戻し、JSONを取得し、それに基づいてDOMを更新する、壊れやすいjQueryイベントハンドラーの長いブロックを取得しています。

少なくとも、クライアント側のテンプレートをいくつかミックスに追加したいと思います。または、JSフレームワークに切り替えて、Djangoアプリをデータベース抽象化レイヤーとして使用することもできます。または、Pythonを知っていて大好きですが、Djangoアプリを放棄して、JS /Node.jsソリューションなどを試してみることができます。

他の誰かがこの状況にありましたか?どのようにそれを解決しましたか?

設計目標

  1. DRY:モデルやテンプレートを複製する必要はありません(少なくとも、必要以上に複製する必要はありません)。
  2. ページにアクセスした訪問者に、サーバー側でレンダリングされた結果を取得してもらいたい。
  3. 訪問者が物事をクリックすると、クライアント側のテンプレートとレンダリングを介してそれを処理し、AJAXインターフェイスへのREST呼び出しを介してサーバーを最新の状態に保ちたいと思います。

だから...どうすればこれを行うことができますか?いくつかのフレームワークとテンプレートシステムへのリンクを集めました。順不同:

dust.js

これは明らかに LinkedInで使用されています 同様の問題を解決するためです。サーバー側でNode.jsを使用しますが、これは理想的ではありません(Nodeを使用したことはありません)が、少なくともJVMベースではありません。また、githubでは休止しているようです。メンテナーがどこに行ったのか疑問に思っているメーリングリストを見つけました。 LinkedInからのブログ投稿は、テクノロジー、特にそれをコンパイルする機能を販売するのに良い仕事をしています。しかし、それはただテンプレートを作成しているように見えます。私が欲しいものにはそれで十分ですか?

口ひげ

このオプションにはPythonとJSの両方の実装があり、人気があるようです...しかし、DjangoでMustacheテンプレートを使用しているように見える人は見つかりません。それは、ブログ投稿に値するのは簡単すぎるからですか、それとも不可能であるか、そうでなければお勧めできませんか?また、かなり制限されています。少なくとも、ある種のMVCJSフレームワークに目を向ける必要があるでしょう。

バックボーン、スパイン、KnockoutJS、EmberJS、JavascriptMVCなど:

とても多くのフレームワークがあり、それは一種の気が遠くなるようなものです。それらはすべて一見完全に良いように見えます。また、このルートに行った場合、アプリの多くを書き直す必要があるようです。実際にこのようなことをすでに行っている人を本当に見つけたいと思います。また、Djangoから来た人を背景として明確な選択肢があればいいのにと思います。それらを評価するために、半ダースの異なるフレームワークを学ぶ必要はありません。

DerbyJS

これは、クライアント側とサーバー側の両方を1つのパッケージで処理するため、面白そうに見えますが、少し未成熟です。彼らはそれを本番環境で使用することに対して警告します、そして私がドキュメントを理解するならば、それはまだどんな形の永続性もサポートしていません、それは...制限しています。それが終わったら、私が欲しいものには完璧になるだろうと私は感じます...

そう....

だから、ええと...今何?誰かがこれらのツールのいずれかを使用して、クライアント側のレンダリングをDjango Webアプリに追加しようとしたことがありますか?どうだった?

31
Cody Hatch

Djangoテンプレートとの完全な統合のために私はこれを見つけました: Yz-Javascript-Django-Template-Compiler 。私はそれを自分で使用したことはなく、残念ながらそれは少し維持されていないように見えます。

Swig は、高速のJSDjangoのようなテンプレートエンジンです。

Pure はコンパイルされたJSテンプレートツールであり、少し考えれば、Djangoテンプレートは通常の有効なHTMLであるため、うまく機能すると思います。

その他の興味深いJSテンプレートライブラリ:

6
Etienne

上記のすべてのフレームワークは、クライアント側でのみ機能します。それは側面ですが、彼らはあなたが直面しているパズルのピースなので、一見の価値があります。

あなたの設計目標は、まさに私が現在のプロジェクトで達成しようとしていることです。私が今やろうとしていることは:

クライアントサイド

Backbone +の使用(ここにいくつかのテンプレートエンジン)

サーバーサイド

Htmlの最初のセットをレンダリングし、Backboneが取得して操作できるJSONデータをレンダリングします(たとえば、ロードされた現在のページ、最大ページなど)。

クライアントの読み込み: http://mysite.com/blog/archive/5

サーバーのレンダリング:

<html>
    <head>
        <script>
            var data = {
                page:5 // Rendered by Server,
                maxPages: 10
            };

            $(function(){
                // Hook up all Backbone stuff, and hook into interaction events
            });
        </script>
    </head>
    <body>
        <!-- Content -->
    </body>
</html>

これにより、デザインポイント2と3が解決されます。サーバーはWebアプリケーションの初期状態をロードし、ユーザーはそこからクライアント側に移動できます。

設計ポイント1:クライアント側では、すべてが正常です。ただし、サーバー側では、テンプレートをそのままレンダリングするためにjsエンジンが必要です。 LinkedInは彼らの記事でこれに言及しています:

  • サーバー側のサポート:検索エンジンクローラーなど、JavaScriptを実行できないクライアントがある場合は、ページをサーバー側でレンダリングする必要があります。一度作成すると、同じdust.jsテンプレートをブラウザーだけでなく、サーバー上でも node.js または Rhino を使用してレンダリングできます。

したがって、2つのオプションで立ち往生しています:

  • node.jsまたはRhinoのいずれかでテンプレートエンジンを使用するか、または
  • 他の技術スタックでサポートされているテンプレートエンジンを見つけてください。

おかしなことに、上記の投稿のおかげで、ほとんどの一般的なスタックで使用できるライブラリがある Mustache がこのニーズを完全に満たしていることに気づいたので、プロジェクトとの統合を検討し始めます。 (Handlebars.jsで使用できるライブラリがあるかどうかはわかりません)これにより、サーバー側とクライアント側の両方でMustache.jsテンプレートを記述し、両端で同じテンプレートを使用してhtmlをレンダリングできるようになります。

編集:「サーバー側」のソリューションは、必ずしも選択した言語/スタックである必要はありません。たとえば、Dust.jsを使用しているという理由だけで、アプリケーション全体をNode.JSでコーディングする必要があります。代わりに、シェルコマンドを使用してコンパイルスクリプトを実行することで取得できる場合があります。

編集:Mustacheには「プリコンパイル」ソリューションがないようです。つまり、テンプレートをクライアント側のレンダリングのためにページに直接レンダリングする必要があります(したがって、キャッシュはありません)。これは100%理想的ではありません。

4
Daryl Teo

私はそれが古い質問であることを知っています、しかし私はどういうわけかここに着きました、それでおそらく他の人はそうします。

また、RIAを構築するためのソリューションを見つけようとしています。これは、可能な限り多くのデバイスで動作し、応答性が高く、パフォーマンスが高く、優れたUXを備えています。 Djangoテンプレートを使用したバックエンドは、必要に応じて適切にフォールバックするオプションを持つように実装されています。

今、私はそれらすべてのjsフレームワークを調べていますが、主にパフォーマンスとアクセシビリティについて少し心配しています。

テンプレートがサーバーに実装されていることを考慮して、バックエンドでレンダリングされ、jsonではなくシッククライアントに送信されるhtmlフラグメントを使用して部分的なDOM更新を行うソリューションに傾倒しています。私にとって最良の選択肢のように見えます。

引用元: http://openmymind.net/2012/5/30/Client-Side-vs-Server-Side-Rendering/

よろしく、マイク

2
okrutny

サーバー側とクライアント側の両方でMustacheを使用しましたが、うまく機能しました。私が使用したプロジェクトは小さなサイドプロジェクトでしたが、結果に本当に満足しており、それをお勧めします。

HTTPサービスをデバッグするためのWebアプリであるこのプロジェクトは、GitHubにあります: Spyglass

1
Justin Voss