2012-02-20 7 views
6

私は、JSONデータ(オートコンプリート結果、カレンダーイベント、タスク、動的フォーム操作など)に大きく依存する新しいrail 3.2企業管理アプリケーションに取り組んでいます。バックエンドシステムはすでにかなり安定しているので、私たちはUIの部分に投資しており、Googleのような他の「ファットクライアント」アプリの動作を反映して、よりウェブアプリケーションにしたいと考えています。この目的を達成するには、Backbone.jsなどのMVC JSフレームワークを使用して、データ操作の優れた部分をUIに委譲し、JSON APIとインターフェースするか、リモートJS js.erbテンプレート)を使用すると、Rubyコードをより多く使用できますか?Rails 3.2のデザインパターンJS重いアプリケーション

私たちは既にいくつかのビューで非常に粗悪なものを使用していますが、前者のアプローチではJSがコード化するのが難しいため、多くの開発者リソースを使用しているようですエンドユーザーにはもっと敏感です。後者のアプローチではレスポンスタイムを犠牲にしてよりシンプルなViewコードが可能になり、すべてがすべて正しく感じられませんが、確かに開発が速く柔軟性が高いことは確かです。

私たちは、JS/Coffeescript/Backbone.jsでたくさんのRails体験を集めた小規模のチームであり、会うべき締め切りがあることを覚えておいてください。私がこの1つを失っている理由は、当社がコードの品質と近代的なデザインパターンへの忠実性に自信を持っていることです。遠いJSを使うことは、悪いショートカット 'なので、皆さんのご意見を本当にありがとうと思います。たぶん私は偏っているだけかもしれない。

+0

一般的に次の名前空間の階層を使用

@module 'MyProject', -> @module 'Model', -> [...] 

:あなたはまた、ヘルパーのウロコ状ことができ

m = new MyProject.Model.MyModel 

:だから、ルート名前空間からそのようなあなたのモデル(document)にアクセスすることができますあなたがタイトなデッドラインにいる場合は、おそらくチームが最も快適であるものに固執すべきです。今は実験する時間ではありません。しかし、RailsでJSON APIを作成することはそれほど難しくないことはすでに知っているでしょう。あなたのチームがJavascriptでうまくいかない場合、おそらくバックボーンでスピードアップするためには時間がかかるでしょうが、そうすれば素晴らしいことをすることができます。あなたは試しているものにいくつかの具体的なユースケースを提供し、アドバイスを得てより多くの人々がチャイムできるようにするべきです。 – PhillipKregg

答えて

2

私はあなたのために決定できません。それは主に締め切りがどれほど近いかによって決まりますが、私はpersonbian.jsのアプローチを好みます。

私は、静的でキャッシュ可能なJSスクリプトと軽いAJAXリクエスト(JSONのみ)を持っていると言うことができますが、他のアプローチでは、より重くてキャッシュできないスクリプトをダウンロードします。

しかし、とりわけ、バックボーンの方法は、コードを整理して保守するのに最適なアプローチだと考えています。

  1. Coffeescriptはすごく素早く学びやすいです。 JS構文を単純化して楽しくします。それは試してみる価値がある。 3000万人で学んだ。

  2. Backbone.jsはすばらしい学習方法です。このアプローチを使用すると、イベントに頼ることができます。これは、私たちが行うことができないものよりはるかにクリーンです。

    アセットパイプラインのおかげで、ビュー/モデル/ルータクラスを別々のファイルに分割することができます。私は私のプロジェクトでの名前空間の中に私のオブジェクトを整理するために少し@moduleヘルパーを追加することで

    class @MyView extends Backbone.View 
        events: 
        'click obj': 'handler' 
        [...] 
    

    :あなたはあなたの背骨は、そのような非常にきれいな構文でオブジェクトを書くことができるのCoffeeScriptする

    感謝。

ただし、良いファイル構成を見つけるのに少し時間がかかります。

gem rails-backboneから始まり、いくつかのジェネレータをレールに似たものにすることができます。私はそれがpersonnaly好きではないが、私はそれが良いスタートだと思う。これには、レールに適合したBackbone.sync機能が含まれています。ここで

編集

@moduleヘルパーについてのいくつかの詳細。私は(require_selfすることを忘れないでください)application.js.coffeeでこれを含める:

私のクラスファイルで
@module = (names, fn) -> 
    names = names.split '.' if typeof names is 'string' 
    space = @[names.shift()] ||= {} 
    space.module ||= @module 
    if names.length 
    space.module names, fn 
    else 
    fn.call space 

@module 'MyProject.Model', -> 
    class @MyModel extends Backbone.Model 
    [...] 

@this.ためのCoffeeScriptのショートカットであることに注意してください。)

ヘルパーは、必要に応じて(NULLの場合)オブジェクトMyProjectMyProject.Modelを作成し、thisにバインドされたMyProject.Modelで指定された関数を実行します。私は

MyProject 
    Model 
    View 
    Router 
    Runtime (to store all runtimes objects and don't pollute the root namespace, easier for debug) 
+0

こんにちはArtimuz、あなたの入力をありがとう。バックボーンの方が良いと私は同意します。バックボーンとリモートJSを使ってアプリケーションの一部を試してみました。バックボーンの実装は、構成が難しいものの、はるかに高速です。この@moduleヘルパーをどのように使用しますか? – marcelowiermann

+0

@marcelowこんにちは。私は耳にうれしい!私の編集を見て、私の '@ module'のことを少し説明します。私はあなたがすぐにあなたのバックボーンで楽になることを願っています。あなたは良いファイル構成を見つけるでしょう。 –