java - Google Web Toolkit (GWT) を本格的な Java Web フレームワークとして使用することは理にかなっていますか?

Question

GWT がプレゼンテーション層全体の基礎として機能する可能性に興味があります。

誰かがこれを成功させたかどうか、または失敗させたかどうかを知りたいと思います。

Answer 1

私は約1年前にGWTで働いていました。当時は素晴らしいアイデアのように思えましたが、いくつかの注意点があります。

• API のいくつかの部分で「落とし穴」の問題がありました。これはおそらく、Java のように動作する個別にコンパイルされた環境用に実際に書いているときに、Java を使用しているかのようにコーディングしているという事実に関連していると思われます。そのため、いくつかの誤った仮定を行います (この場合、ネストされた値をフロントエンドに渡します)。gwt コンパイルに 32 ビット jvm を使用するように私の ant スクリプトを書き直していた別の方法があったと思います。
• 外観を微調整するのに少し時間を費やしました - 完成したプロジェクトを展開したことがないので、これがプロのレベルに到達するのにどれだけの作業が必要かはわかりませんが、(論理的に)そうなるように見えましたこれは、swing インターフェースを微調整することに匹敵します。視覚的には、html よりも少し扱いに​​くいかもしれません。
• 最終製品では ajax は非常に隠されているため、パフォーマンスが低下した場合にどうすればよいかについて、いくつかの懸念がありました。

そうは言っても、それは間違いなく遊ぶ価値があるように思えます。私の経験は、インターネット時代のずっと昔のことであり、特に現在はおそらくはるかに成熟していることを考えると. また、ほとんどの MVC フレームワークから GUI コードを開発する方法が非常に異なる (そして斬新な) 方法であることも指摘しておく価値があります。それ以外の理由がなければ一見の価値があります。

非常に要求の厳しいグラフィカルな要件を持つ高負荷のプロフェッショナルなサイトを構築している場合、GWT はおそらく適切な選択ではありません。

Answer 2

GWT がプレゼンテーション層を処理するとおっしゃいました。ビジネス層も Java でやりますか？その場合は、まさにこれを行うIT Mill Toolkitを紹介したいと思います。これは、GWT を使用して GUI コンポーネントをレンダリングし、アプリケーションを完全に Java で実行できるようにするツールキットです。造語しようとしている用語は「サーバー主導の RIA」だと思います。

私は PHP のバックグラウンドを持っていますが、すぐにツールキットが好きになりました。でも、これ以上は何も言わず、あなた自身の判断に委ねたほうがいいでしょう。

免責事項: 私は IT Mill で働いていますが、それは私の意見とは関係ありません。

Answer 3

GWT は比較的新しいものです。コードベースが大きくなるにつれて、コンパイルプロセスは少し遅くなる傾向があります。これを使用したとき、より洗練されたウィジェットのレイアウトとレンダリングに多くの問題が見つかり、エミュレーターは実際のサーバーとはまったく異なる動作をしました。また、右から左へ記述する言語の i18n にも問題がありました...

全体として、GWT には (いつもの?) 若い技術の問題があります。ただし、名前を付けたAjaxifyingなど、特定のことは非常に簡単になります。

Answer 4

プレゼンテーション層全体を GWT で処理する大規模な HR ポータル アプリケーションを開発しました。バックエンドはSpringです。それはすべて非常にうまく機能し、UI はユーザーから非常に好評です。非常に重要なことは、新しい機能の追加とアプリケーションの保守が簡単であることです。Javascript ライブラリを使用して、同等で保守可能なことを行うのははるかに難しいと思います。

なんらかのクライアント サイド フレームワークが必要です。そうしないと、最終的に作成することになります (私たちが行ったように!): 私たちのアプリはGWT ポートレット(無料でオープン ソース) 上に構築されています。

さまざまな展開に合わせてアプリをスキニングするために HTML フラグメントを使用し、各「ページ」のレイアウトは XML ファイルに保存されます。

Answer 5

非常に大規模なプロジェクトでこれを行いましたが、制限、長所、短所があることを知っている限り、うまく機能します。おかしなことに、CSS を使用して、他の HTML ページと同じようにスキンを付けただけなので、プレゼンテーションは私たちにとって最も手間がかかりませんでした。プロジェクトは稼働し、問題なく実行されたので、不満はありません。

私が見つけた落とし穴は、ここにあります：

最大の GWT の落とし穴?

Answer 6

このraibleビデオのそれについてのいくつかの良い情報：http：//raibledesigns.com/rd/entry/my_drunk_on_software_interview

Answer 7

GWT 自体は UI 拡張ライブラリであり、フレームワークではありません。これを Google App Engine で使用すると、基本的なフレームワークが完成します。(それは別の話です。私がそれを見ているうちに、それを私たちのアーキテクチャに含めないことに決めました)。

それは素晴らしいライブラリです。ただし、これはライブラリであるため、アーキテクチャが許す範囲でしか機能しません。

ANT に関する限り、64 ビット コンパイラで問題はありません。

<java failonerror="true" fork="true" classname="com.google.gwt.dev.Compiler" dir="${dir.GWTCompile}"> <-- dir.GWTCompile は GWT を含むディレクトリです --> <classpath> クラスパス </classpath> <jvmarg value="-${gwt.maxMem}"/> <arg value="@{gwt.baseModule}" /> <arg value="DEBUG" /> <arg value= "-strict" /> </java>

生成されたコードに関する限り、それを確認したい場合は、すべてが戦争にあります。（こちらもオープンソースですので、そちらでご覧いただけます。）

コンパイル プロセス中に GWT が行うこと: さまざまなブラウザー セット用に JS ライブラリの複数のコピーを作成します (コンパイルに数分かかる場合がある理由の 1 つ)。必要に応じてこれらを追加/削除できます。これにより、ダウンロードする必要がある JS パッケージが減り、速度が向上します。if (EI) this else if (FF) that. ただし、ローカル デバッグを行う場合 (少なくとも Eclipse では)、待機する必要はなく、それをビルド サーバーに任せることができます (または、手動でビルドして展開する必要がある場合 (ネアンデルタール人))。

GWT の欠点。これは JavaScript クライアント側 (ほぼ純粋) であるため、それをサポートしていないものや、いずれかのバージョンをサポートしているものには使用できません。そのため、iPad や iPhone などの場合、これらのギャップを埋めるように設計された追加のライブラリ (mgwt など) を使用しないと、いくつかの問題が発生する可能性があります。