3

私は標準的な Rails アプリケーションを開発していますが、これまで AJAX は使用しておらず、古き良き HTML のみを使用しています。私の計画は、「リモート」リンクとそのようなものすべてとJS応答のサポートを繰り返し追加することです.JSサーバー側の生成は非常に悪いことを知っていますが、非常に便利で、簡単で、高速で、これにより、アプリケーションが十分に機敏になり、i18n はすぐに使用できます。

純粋な JSON アプローチを使用すると軽量になりますが、多くのクライアント側のコーディングが必要になります。

ここで、このアプリケーションでユーザーがメールボックスを持っていると想像してください。ユーザーはページをリロードせずにほとんどまたはすべてのアクションを実行できるため、ページを手動で更新しない限り、メールボックス カウンターは決して変更されません。

では、ここで質問があります。これを処理する最善の方法はどれですか?

  1. Ember (データ バインディング用) を使用し、Ruby のある種のハンドルバー実装を介してレールとビューを共有することを考えました。これは非常に素晴らしいことですが、開発者 (私) にとってはあまり透過的ではありません。私は ember が使用するハンドルバー ビューのみを記述する必要があると思いますが、残りは元の形式で記述できますよね?

  2. もう 1 つのオプションは、ある種のイベント システム (EventSource かな?) を使用し、JS ビュー アプローチを使い、それらのイベントをリッスンすることです。それらは JSON オブジェクトである必要があり、それらを処理できるようにクライアントをコーディングする必要があると思います。これは少し面倒に思えます。アプリがホストされている heroku (faye?) のソリューションが必要です。ヒントはありますか？

私は、ember のアプローチの方がより堅牢だと思いますが、かなり複雑なようです。サーバー側とクライアント側で同じことを繰り返したくありません。

編集：

これは多かれ少なかれオプション＃2です。

4

1 に答える 1

0

JavaScript フレームワークを使用する利点の 1 つは、アプリケーション全体を連結して 1 つの JavaScript ファイルに圧縮できることです。最新のブラウザが積極的に JavaScript をキャッシュする場合、ブラウザは最初のページ読み込み後にこれらのアセットをリクエストする必要がなくなります。

JavaScript フレームワークを使用するもう 1 つの利点は、独自の API のコンシューマーになる必要があることです。モバイル アプリケーションまたはサード パーティがアクセスする可能性がある場合、自分で使用するためにアプリケーションの API を具体化することで、将来的には作業が減る可能性があります。

アプリケーションがすべての要求に同等の HTML 応答で応答する必要がない場合は、JavaScript フレームワークを使用する説得力のあるケースを作成できると思います。

アプリケーションが同等の HTML テンプレートを使用してすべての要求に応答する必要がある場合、これらの利点の多くが失われる可能性があります。Ember コアは比較的積極的であり、このスタイルのプログレッシブ エンハンスメントのサポートに反対しています。このように JavaScript フレームワークを使用するためのツールが比較的不安定で未熟であることを考えると、これを達成するためにオプション 2 を使用する傾向があるかもしれません。

于 2013-10-31T02:59:50.760 に答える