GWT on Railsはクライアントとリソースジェネレータ、移行サポート、非同期RESTfulクライアントサポートとRakeオートメーションを提供することによってGWTクライアントサイドのコンパイル済みのJavaScriptとRails RESTfulウェブサービスを統合する。2,3のステップのみでいいのだ。GWT Clientジェネレータ、GWTモデルジェネレータでGWTクライアントが準備される。
GWT On RailsはJSON Request Railsプラグイン(source)と、インターフェースをとるためにGWT-Rest(source)を使用する。
RailsへのAjax統合がすでに整っている一方、Javaを非直接的にRailsに導入するのは一般的なパターンではない。この疑念を追い、InfoQはRailsプラグイン上でGWTを書くという事への動機を探るためJon氏を尋ねた。
フレームワークを拡張する新たなプラグインをみるのは良いことですがGWT on Railsは開発サイクルにおいて不必要にJavaに重きをおくことによってRailsの理念に反することになるのではないでしょうか?
JavaのほとんどはGWT on Railsに属さないJEEに重きをおいています。クライアント側のGWTはJavaScriptを 生成するためにJava言語を使用しています。重いサーバサイドのプラットフォームはそれを使って描画を行いません。過去にGWTを使うことはサーバサイ ドのJavaにも関連していましたが、GWT on Railsはこのつながりを壊すのです。もちろん、これをするのは私が初めてではありません。JanRainはPibb(source)を構築するためクライアント側でGWTを、サーバサイドでPythonとRailsのミックスを使用したのです。
私は、ほとんどのアーキテクチャ的決定がある特定の文脈においてのみ有利になり得るトレードオフであることに気付きました。私にとってほとんどのクロスブラウザデバッグタイムシンクを防ぐことに加え、GWTリリースとともに、速さを増す、迅速で、コンパイルされたJavaScriptを持つということは私が研究した代替策よりもRailsの”機能するだけ”という理念に近いものだったのです。
真剣にGWT On Railsを使用しようとしているアーキテクトがいるのでしょうか?(既存のGWTクライアントを持っていてRailsに移行したいという状況は別として)
JavaからRailsへのサーバサイドでの移行に加えて、あなたが言ったように優れたJavaScriptツー ルキットでデスクトップライクなインターフェースを作りたいと思っているRailsデベロッパのケースもあります。GWT on RailsはGoogleの高品質なツールキットで構築されていて、またRailsに友好的なRESTfulクライアント、サーバサイドでクライアントサ イドのJavaScriptモデルをActiveRecordと同期に保つツールを付加します。
原文はこちらです:http://www.infoq.com/news/2008/01/who-needs-gwt-on-rails