カスタム (特定の種類のイベント、編集) カレンダー システムを備えた、データベースに基づくインタラクティブな AJAX Web アプリケーションを作成したいと考えています。これには非常に多くの JavaScript と AJAX が必要になるため、インターフェイスには Google Web Toolkit を、サーバー サイドには Ruby on Rails を考えました。
Google Web Toolkit は信頼性が高く優れていますか? Google Web Toolkit を選択した場合に考えられる潜在的なリスクは何ですか? サーバー側でRuby on Railsと簡単に組み合わせることができますか? それとも、jQuery のような JavaScript ライブラリを直接使用する必要がありますか?
一部の HTML を除き、Web 開発の経験はありませんが、経験豊富なプログラマー (c++、java、c#) であり、このプロジェクトでは無料のツールのみを使用したいと考えています。
RoR は、実際には、REST を適切に使用している限り、GWT がうまく機能するように作られているものの 1 つです。これは Google Web Toolkit Applications book にあり、この種のアイデアを使用した本からのデモをここで見ることができます。全く問題ないとは言えませんが、サポートはしっかりしていると思います。
RoR/GWT を簡単にするためのすばらしいプロジェクトがここにあります(MIT ライセンス)。まだ試してみる機会はありませんが、かなり考え抜かれたようです。問題の 1 つは、Rails 2.1 ではまだ完全にテストされておらず、2.0 だけであるように見えることです。そのため、いくつかの (おそらくマイナーで修正可能な) エラーが発生する可能性があります。
GWT を ROR、PHP などの Java 以外のバックエンドと統合しようとしている場合は、GWT 1.5 が JavaScript オーバーレイ タイプをサポートするようになったことを覚えておく必要があります。この機能を使用すると、ネイティブ JavaScript オブジェクトの上にマップできるクラスを記述して、これらのオブジェクトのプロパティやその他の拡張機能のアクセサー メソッドを簡単に提供できます。
詳細については、このリンクを参照してください: JavaScript オーバーレイ タイプ
したがって、AJAX 呼び出しを介してバックエンドから JSON でエンコードされたデータを返し、それを JavaScript オブジェクトに解析してから、作成したオーバーレイ クラスを使用して GWT Java コードを介してデータにアクセスできます。または、ページをレンダリングするときに、静的構成データを JavaScript オブジェクトとしてレンダリングし、このメカニズムを介して読み込むことができます。データを取得するために AJAX 呼び出しを行う必要はありません。
JAVA を知っていて、それをホストできる場所 (Tomcat や GlassFish コンテナーなど) がある場合は、バックエンドに Ruby を使用するよりもはるかに多くのことをお勧めします。主な理由は、すべてのオブジェクトを共有し、組み込みの RPC メカニズムを使用できることです。私はかなり多くのプロジェクトでこれを行ってきましたが、Java オブジェクトを何かに変換してから元に戻す必要がないため、コードのエラーが発生しにくいことは言うまでもなく、大幅な時間の節約になります。
以前、Rails で to_json 関数を使用して GWT と Rails をリンクし、GWT で JSON を読み取ったことがあります。すべてサポートされていますが、JAVA でバックエンドを実行するよりもはるかに面倒です。
もちろん、安価なホスティングを利用している場合、Java コンテナーはほとんど問題外です。その場合、Rails が次善の策になると思います。
GWT は非常に高品質で、優れたコミュニティがあります。ただし、物事の外観を調整したい場合は、CSS を知る必要があります (そうする必要があります)。必要に応じて、CSS は通常の Web と同じように多くのレイアウトを行うことができます。GWT-ext や ExtGWT などのライブラリは、魅力的な「すぐに使える」外観を備えていますが、価格が高い (アプリのサイズが大きい) ため、少し役立ちます。
GWT は、多くの可能性を秘めた素晴らしいフレームワークです。ただし、それはまだかなり新しいことを覚えておいてください。いくつかの未解決のバグがあり、本当に悩ましいことがあります。通常、それらを乗り越えるには醜い回避策が必要です。コミュニティは素晴らしいですが、遅かれ早かれ、Google がまだ解決できないいくつかの問題に直面することになるでしょう。
でもねえ、私はそれのために行くと言います。GWT の可能性は素晴らしく、その未来は明るいと確信しています。
Java の経験はあるが Javascript/CSS の経験がない場合、GWT は命の恩人になるでしょう (もちろん、それらを学びたい場合を除きます)。CSS には非常に多くの面倒な詳細があります。IE6 でのみ発生する 2 ピクセルのずれの修正に半日を費やすことも珍しくありません。
バックエンドに ROR を使用することがどれほど簡単かはわかりません... GWT ajax 通信は単なるサーブレットであるため、可能です。しかし、サーバーが Java も使用していない場合は、Java オブジェクトをやり取りするための非常に優れた機能が提供されます。
GWT を使用して Java ですべてをコーディングでき、既存のサードパーティの JavaScript ライブラリを GWT と統合できます。これはとてもいいです。私は RoR をあまり使用したことがないので、それについては何も言えません。
You should definitely use GWT for a new project (it's pretty easy to use in an old project too).
I my experience it's very fast to learn and use. The compiled javascript code is much better than anything you could ever write by hand and it works fast too.
Another benefit is the ability to debug you're code (which is hell with javascript alone)
このブログには、GWT の多くの経験豊富なユーザーからの意見があり、いくつかの優れたディスカッション ポイントがあります。私は個人的に、さまざまな UI フレームワークで豊富な経験を持っています。2セント追加します。GWT の基本的な長所と短所を見てみましょう
基本的な利点
GWT は Web 層プログラミングを Java に取り入れます。したがって、Java の明らかな利点が発揮され始めます。オブジェクト指向プログラミングを提供します。また、優れたデバッグとコンパイル時のチェックも提供します。HTML と Javascript を生成するため、ジェネレーター内の複雑さを隠すこともできます。
根本的な欠点
不利な点は、同じステートメントから始まります。GWT は Web 層プログラミングを Java に取り入れます。JAVA の知識があれば、ビジネス ロジックを記述するための代替言語を探し出すことはおそらくないでしょう。それは自給自足であり、素晴らしいことです。しかし、JAVA アプリケーションの構成を作成する場合は、. プロパティ ファイル、データベース、XML などを使用します。設定を JAVA クラス ファイルに保存することはありません。よく考えてみてください、それはなぜですか？
これは、構成が静的データであるためです。多くの場合、階層が必要です。読みやすいはずです。コンパイルは必要ありません。JAVA プログラミング言語の知識は必要ありません。要するに、それは別の球技です。問題は、それが私たちの議論にどのように関係するかです。
ここで、Web ページについて考えてみましょう。Web ページを作成するとき、ビジネス ロジックを作成すると思いますか? 絶対違う。Web ページは単なる設定です。階層的なコンテナとフィールドの構成です。Web ページから取得して表示するデータのビジネス ロジックを記述する必要があり、Web ページ自体を作成する必要はありません。
前のパラグラフは非常に強い声明を出しています。これにより、HTML および XML ベースの Web ページが依然として最も人気がある理由が説明されます。XML は、ビジネスで構成を記述するのに最適です。フレームワークでは、Web ページをビジネス ロジックから明確に分離できる必要があります (MVC フレームワークの目標)。これを行うことにより、Web デザイナーは、プログラミング言語の複雑さを気にすることなく、XML を構成するだけで、視覚化と芸術性のスキルを適用して、見栄えのする Web ページを作成できます。開発者は、ビジネス ロジックを記述するためにビジネス JavaVA を最大限に活用できます。
最後に、影響について直接的に話しましょう。GWT はこのプリンシパルを破るため、必ず失敗します。Web ページを作成するにはマルチスキルのプログラマーが必要になるため、GWT アプリケーションの開発コストは非常に高くなります。必要なルック アンド フィールを実現するのは非常に困難です。不必要なコンパイルのため、Web ページの変更にかかる時間は非常に長くなります。最後に、JAVA で Web ページを作成しているため、ビジネス ロジックで簡単に破損してしまいます。知らず知らずのうちに、回避しなければならない複雑さを導入することになります。
最近、GWT のいくつかの欠点について書きました。主な欠点は次のとおりです。アプリケーションの一部を変更するための導入サイクルが長く、学習曲線がかなり急です。ベテランの Java プログラマーとして、2 番目の問題はそれほど問題にならないはずです。別のバックエンドを使用すると、最初の問題も緩和されます (アプリケーションの「サーバー」部分を変更する場合は、完全な再デプロイが主に必要になるため)。
また、Rails フレームワークの利点と Java VM の使用を提供するGrails (「Groovy on Rails」) を検討することもできます。
私たちのチームは最近同じ質問をしましたが、GWT を使用することを選択しました。これは特に、デザイナー プラグインによって、チーム内の Java 以外の専門家が GWT で作業しやすくなったためです。この選択をする人は、GWT Designer プラグインを使用しないように注意してください !! IE8 と互換性のある GWT アプリケーションを作成するために (少なくとも 1 年は) 更新されていません。
私たちのチームは、Chrome、FF、Safari で完全に機能するアプリケーション レイアウトをほぼ完成させました。それから彼らはIEで爆発しました。IE 7 は部分的なページをロードしますが (複合インクルードはロードしません)、IE8 はアプリケーションをロードすることさえできませんでした。ハングしただけです。
デザイナー プラグインには、ユーザーが IE と互換性のない CellTable ウィジェット (CellTable、DeckPanel、Horizontal Panel、Vertical Panel など) を追加できるボタンがあります。これらは、デザイナーの支援なしに Java でレイアウトをやり直さなければならない場合に、激しい痛みを引き起こします。
経験豊富な GWT ユーザーは気に入っていますが、デザイナー プラグインはあなたを殺します。