Emberjs、サーバー側とクライアント側、オールイン？

Question

私はEmber.jsを探していましたが、それは本当に素晴らしいようですが、懸念しているのは私が気にすることができないことです。

私は最終的にすべてのクライアント側を移動し、私のアプリケーションをある時点で1ページのアプリケーションにする必要がありますか？

は私がエンバーを使用して、クライアントとサーバーの間で通信するための最良の方法は、RESTでこれまでのところ...

を明確にしましょう。それは素晴らしく見えますが、私が気に入らないのは、すべてのテンプレートを初めて読み込むことです。私のサーバーのすべてのロジックをクライアントに移動する（または、私はこれをすべて間違っていますか？）、私のサーバー側がロジックレスのREST APIになるように見えます。

また、gridsのようなJavaScript（Ajax対応）コンポーネントがいくつかあります。Yii Frameworkを使用しています。すでにアプリケーションで作業しているたくさんのものを書き直す必要なく、私はどのようにしてnavigationのすべてのことをemberとやりとりさせることができますか？

私はログインページ（または状態）にいます。ログイン後、Yiiで簡単に使えるgridを表示する必要がありますが、Emberを使用している場合は通常どおりにグリッドディスプレイを表示できますか？グリッド用のハンドルバーテンプレートとそれを制御するJavaScriptをあらかじめロードする必要がありますか？

Answer 1

いいえ、すべてをクライアント側に移すべきではありません。特に認証と検証はバイパスできます。

Emberjsに移動するのはMVCのyii-s View部分です。コントローラーはJSONを出力します。あなたはCGridViewのようなのYiiのUIクラスを使用するべきではありません残り火でのYiiのプレゼンテーションロジックを交換するので、データは、その後などエンバールーティングおよびコントローラ

を通じて残り火モデルの一部にマッピングされる

。 それらを混ぜることは可能かもしれませんが、それはよいアイデアのようには見えません。あなたはEmberで自分自身を動かす必要があります。私の経験で

http://www.yiiframework.com/wiki/409/ember-js-with-yii-rest-backend-demo-application/

Answer 2

ここにYiiパースペクティブを追加するだけです。グリッドビュー/リストの「魔法」の多くは、データプロバイダ内で（複雑な検索、並べ替え、フィルタリングのために）、データをモデルの解析フィールドでフォーマットすることによって発生します。

同じ概念のサーバー側を利用して、自分のウィジェット内から最終的なJSON、ページ番号付けしたものだけを出力することができます。すべてのデータ/構成処理の後に、ビューではなくグリッド・ビューをオーバーライドしてjsonを出力することもできます。

HTMLではなくJSONがダウンしたら、グリッドのフロントエンドを複製するのは非常に簡単ですが、実際にはあまり機能はありません。

これは理想的ではないかもしれませんが、ページ分割、検索、フィルタリングのすべてのロジックをクライアント側に移動する必要はありません。

TL; DR;
すでに機能が構築されているYiiウィジェットをオーバーライドして、HTMLではなくJSONを出力するために使用します。

Answer 3

、 あなたは自分のサーバーサイドJSで既存のコントローラーとアクション（CLIによって、またはhttp）にアクセスすることができます。 node.jsと統合された既存のアプリでも同じことをしました。

このメリットは、新しい実装を完全にサポートしていないブラウザや、最初にjavascriptでうまくいかない検索ボットの代替として、コードをそのまま使用できることです。

私はすべてapp in my modelsと書いていますが、とにかくデータコントロールなどです。実際の機能はコマンドです。ブラウザがサポートされていない場合やjavascriptが無効になっている場合は、UrlManagerと実際のコントローラとアクションを使用して、アンカーとページの読み込みがすべて通常の方法に戻ります。それらのコントローラーは簡単なアクションcall the commandsです。 json出力をビュー用の使用可能なデータに変換するヘルパーが必要です。

ページロードは、デフォルトのphpビューとコントローラービューが既に存在するため、表示されます。