個人的にはCoffeescriptは問題ありませんが、ほとんどのロジックではなく、Railsアプリのサポートプレーヤーにしたいと思います。私が見ることができることから、RailsでBackbone.jsまたはSpine.jsを使用する場合は、まだ多くのロジックを複製する必要があります。これらのフレームワークのメリットを享受したり、rack-pjaxだけを使用してリアルタイム更新用のjsを使用した基本的にシングルページアプリを作成したりすることはできませんか？
2548 次
2 に答える
1
さて、あなたは何を達成したいですか？これ以上ページを更新しませんか？その場合、rack-pjaxが機能するはずです。より高速なUIや応答性の高いUIが必要な場合は、良い解決策にはならないのではないかと思います。
シングルページアプリは、サーバーの負荷と複雑さを大幅に軽減し、viewlogicとserverlogicの間に優れた抽象化があるため、推奨されるimoです。
サーバーは基本的にAPIであり、クライアントはすべてのAPIデータをブラウザーにレンダリングします。このようにして、サーバーは大幅に簡素化され、実行する作業が大幅に少なくなります。（勝つ！）
クライアント側でも、多くの改善が見られます。正しく実行された場合、データに加えられたイベントと状態変更に基づいて、それ自体が継続的に再レンダリングされます。このアプローチにより、UIレイヤーでの結合（および重複）が大幅に減少し、ユーザーのUIの応答性が向上します。（勝つ！）
それについてあまり気にしない場合は、先に進んでpjaxを使用してください:)
ただし、JSフロントエンドを使用して既存のサーバーサイドビューレンダリングアプリをシングルページアプリに書き換えるのは難しい作業であることに注意してください。それはおそらく大規模な書き直しに終わるでしょう。また、JSフロントエンドでページの一部だけを書くことを試すこともできます。
于 2012-02-15T15:27:35.607 に答える
0
Rack-pjaxは、ブラウザがリクエストごとにページを更新するのを防ぎますが、サーバーはリクエストごとにHTMLページ全体を送信します。ページが更新されない「シングルページ」アプリが目標の場合、rack-pjaxは機能しますが、読み込みの代わりにJSONを処理するフレームワークを使用すると、帯域幅を大幅に節約し、応答性の高いアプリを使用できます。ページ全体。
シンプルなアプリの場合は、BackboneやSpineなどから始めることをお勧めします。より複雑なアプリの場合は、これらの小さなフレームワークを使用して多くの定型コードを記述していることにすぐに気付くでしょう。おそらく、EmberやCappuccinoのようなものに手間のかかる作業のほとんどを処理させるほうがよいでしょう。
シングルページアプリが必要な場合は、ロジックの一部またはほとんどがフロントエンドに配置され、javascriptで直接記述されるか、coffeescriptで記述されてjavascriptにコンパイルされます。もちろん、サーバーには特定のロジックが必要です（検証など、JSコードに検証ロジックがある場合でも、ユーザーがサーバーに不正なデータを送信できる、または送信することを常に想定しています）。
于 2012-03-01T12:09:11.500 に答える