GWT の最大の落とし穴?[閉まっている]

https://stackoverflow.com/questions/99866

01-07-2019
|

質問

私は現在、GWT を使用して実装することを選択したプロジェクトの開始/途中にいます。GWT (および GWT-EXT) を使用する際に、克服できなかった大きな落とし穴に遭遇した人はいますか?パフォーマンスの観点からはどうでしょうか？

私たちがすでに見たり聞いたりしたことには次のようなものがあります。

Google がコンテンツをインデックスに登録できない
CSS とスタイルは全体的に少し不安定なようです

これらの項目に関する追加のフィードバックもお待ちしています。ありがとう！

解決

最初に言っておきますが、私は GWT の大ファンです。確かに落とし穴はたくさんありますが、すべてではないにしても、ほとんどを克服することができました。

問題： コンパイル時間が長い。プロジェクトが大きくなるにつれて、コンパイルにかかる時間も長くなります。コンパイルに 20 分かかるという報告を聞いたことがありますが、私の場合は平均して約 1 分です。

解決： コードを個別のモジュールに分割し、変更された場合にのみビルドするように Ant に指示します。また、開発中は、1 つのブラウザー向けにビルドするだけでコンパイル時間を大幅に短縮できます。これを行うには、これを .gwt.xml ファイルに追加します。

<set-property name="user.agent" value="gecko1_8" />

ここで、gecko1_8 は Firefox 2 以降、ie6 は IE などです。

問題： ホストモードは (少なくとも OS X では) 非常に遅く、JSP や Rails ページなどを編集してブラウザで更新を押したときに得られる「ライブ」変更に匹敵するものには程遠いです。

解決： ホストモードにより多くのメモリ (私は通常 512M を割り当てました) を与えることもできますが、それでも遅いため、GWT を十分に使いこなせるようになると、これを使用しなくなります。大量の変更を加えてから、1 つのブラウザ用にコンパイルし (通常は 20 秒相当のコンパイル)、ブラウザで [更新] をクリックするだけです。

アップデート：GWT 2.0 以降では、新しい「開発モード」を使用するため、これは問題になりません。これは基本的に、選択したブラウザでコードを直接実行できるため、速度が低下せず、さらにファイアバグや検査などができることを意味します。

http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM

問題： GWT コードは Java であり、HTML ページのレイアウトとは異なる考え方を持っているため、HTML デザインを取得して GWT に変換することが難しくなります。

解決： これにも慣れてきますが、残念なことに、HTML デザインを GWT デザインに変換するのは、HTML デザインを JSP ページに変換するなどの処理よりも常に遅くなります。

問題： GWT は理解するのに少し時間がかかりますが、まだ主流ではありません。つまり、チームに参加したり、コードを保守したりするほとんどの開発者は、コードを最初から学ばなければならないことになります。

解決： GWT が普及するかどうかはまだわかりませんが、誰を雇用するかを会社が管理している場合は、GWT を知っている人、または学びたい人をいつでも選ぶことができます。

問題： GWT は、jquery や単なる javascript のようなものと比較すると大ハンマーです。これを実現するには、単に JS ファイルを含めるよりもはるかに多くのセットアップが必要です。

解決： それらに適した小規模で単純なタスクには、jquery などのライブラリを使用します。AJAX で本当に複雑なものを構築する場合、または RPC メカニズムを介してデータをやり取りする必要がある場合は、GWT を使用します。

問題： 場合によっては、GWT ページにデータを設定するために、ページの最初の読み込み時にサーバー呼び出しを行う必要があります。必要なデータをフェッチしている間、そこに座って読み込み中のシンボルを眺めているのは、ユーザーにとって煩わしい場合があります。

解決： JSP ページの場合、ページは HTML になる前にサーバーによってすでにレンダリングされているため、実際にすべての GWT 呼び出しを実行し、それらをページにプリロードして瞬時にロードすることができます。詳細については、こちらを参照してください。

GWT 呼び出しを事前シリアル化することでページの読み込みを高速化します

私はウィジェットの CSS スタイル設定に、すぐに使用できるかどうかにかかわらず、問題が発生したことはありません。それが落とし穴だという意味がわかりません。

パフォーマンスに関しては、一度コンパイルされた GWT コードは高速であり、AJAX 呼び出しはほとんどの場合、ページ全体を更新するよりも小さいことがわかりました。ただし、これは GWT に特有のものではありません。 JAVA バックエンドは非常にコンパクトです。

他のヒント

私たちはほぼ 2 年間 gwt に取り組んできました。私たちは多くの教訓を学びました。私たちは次のように考えています。

サードパーティのウィジェットライブラリ、特に gwt-ext は使用しないでください。デバッグ、開発、実行時のパフォーマンスが低下します。これがどのようにして起こるかについて質問がある場合は、私に直接連絡してください。
gwt を使用して、アプリの動的部分のみを入力します。したがって、多数のフィールドとの複雑なユーザー操作がある場合です。ただし、付属のパネルは使用しないでください。既存のストックデザイナーが提供するページを考えてみましょう。アプリのコントロールを含む領域を切り出します。これらのコントロールを onModuleLoad() 内のページにアタッチします。こうすることで、デザイナーの標準ページを使用でき、すべてのスタイル設定を gwt の外部で行うこともできます。
アプリ全体を 1 つの標準ページとして構築し、すべての部分を動的に構築しないでください。項目 2 で私が提案したことを実行すれば、いずれにしても、このようなことは起こりません。すべてを動的に構築すると、中規模から大規模のアプリのパフォーマンスが低下し、大量のメモリが消費されます。また、私が提案していることを実行すると、戻るボタンがうまく機能し、検索エンジンのインデックス作成などもうまく機能します。

他のコメント投稿者からもいくつかの良い提案がありました。私が使用する経験則は、標準の Web ページを作成するのと同じようにページを作成することです。次に、ダイナミックにする必要がある部分を切り出します。それらをIDを持つ要素に置き換えて使用します RootPanel.get( id ).add( widget ) それらの領域を埋めるために。

私たちが遭遇した落とし穴:

GWT EXT のようなものを使用すると多くのメリットが得られますが、JavaScript ライブラリの上でこの種の薄いベニヤを使用すると、デバッグ機能が失われます。GWT EXT テーブルクラスで何が起こっているかを (IntelliJ デバッガー内で) 検査できないため、私は何度も机に頭をぶつけました。分かるのは、それが JavaScriptObject であることだけです。これにより、何が問題になったのかを把握することが非常に困難になります...
チームに CSS を理解している人がいない。私の経験から言えば、その人が専門家でなくても問題ありませんでした。ある程度の実務知識があり、必要に応じてグーグルで検索できる適切な用語を知っていれば十分です。
ブラウザー間でのデバッグ。アウトプロセスホストモードに注目してください[1][2][3]、うまくいけば GWT 1.6 で登場します...現時点では、ホストモードで問題を解決してから、[コンパイル/参照] ボタンを使用して、他のブラウザでプレイする必要があります。Windows で作業している私にとって、これは自分の作業を FireFox で表示し、FireBug を使用して調整して改善できることを意味します。
IE6。IE 6 でレンダリングがどれほど異なるかは驚くべきことです。私はブラウザに従って最も外側の「ビューポート」にスタイルを適用するアプローチを採用し、次のような CSS ルールを持たせることができます。
```
.my-style { /* stuff that works most everywhere */ }

.msie6 .my-style { /* "override" so that styles work on IE 6 */ }
```

最後に、役立つエディターを必ず使用してください。私は IntelliJ を使用しています。これには GWT のスマートな機能がたくさんあります。たとえば、JRE エミュレーションで処理されないクラスを使用しようとすると、それが通知されます。ウィジェットのスタイルを指定し、そのスタイルをまだ定義していない場合、コードには小さな赤い波線が表示されます...または、CSS を見ると、単一のルールで競合する属性を指定したことがわかります。(まだ試していませんが、バージョン 8 では、「ローカル」および「非同期」の RPC インターフェイスと実装の同期を保つなど、さらに優れた GWT サポートが提供されていると理解しています。)

今後数か月以内にリリースされる予定の GWT 2.0 では、議論されている多くの問題が解決されます。

html/xml のような構文を使用してレイアウトを作成する
動的スクリプトの読み込み - 最初は重要な JS のみがダウンロードされます。残りは必要に応じてダウンロードされます
ブラウザ内ホストモード - これにより、他の利点の中でも特に議論されたホストモードの速度の問題が解決される可能性があります。
「コンパイラの最適化」 - コンパイルの高速化が期待されます

Google I/O での GWT 2.0 プレビュービデオ

「克服できない」わけではありませんが、基本的なことで少し苦痛です。

日付の処理:

GWT は非推奨の java.util.Date これにより、クライアント側で日付を処理するときに予期しない動作が発生する可能性があります。 java.util.Calendar GWT ではサポートされていません。詳細はこちら.

関連する問題の例:

すでに述べた点にいくつかの点を追加します。

データバインディング/検証。GWT には、そのままではデータバインディング/検証のサポートがありませんが、この分野に関するプロジェクトがいくつか生まれ始めています。次のようなことをたくさん書いていることに気づくでしょう。

TextField fname, faddress;
...
fname.setText(person.getName());
faddress.setText(person.getAddress());
...

遅延読み込み。gwt はクライアント側にあるため、遅延読み込みは実際にはオプションではありません。次のことを行うには、RPC とドメインオブジェクトを慎重に設計する必要があります。
- 必要なすべてのオブジェクトデータを送信します
- すべてのデータを熱心に取得することを避ける
- また、プロキシやシリアル化不可能なオブジェクトを送信しないようにする必要もあります。休止状態4gwt はこれらの点に役立ちます。
UIデザイン。Java で UI (パネル、ボタンなど) を視覚化するのは、HTML よりも困難です。
履歴サポート。GWT には History サブシステムが同梱されておらず、適切な URL やステートフルブックマーク用のサブシステムも同梱されていません。自分でロールする必要があります (ただし、履歴トークンがサポートされており、これが始まりです)。これは、私の知る限りすべての AJAX ツールキットで発生します。

私の意見では、GWT には、この「スレッド」で言及されているすべての問題をすぐにサポートできるフレームワークがありません。

私は現在、GWT EXT と混同しないように EXT GWT (GXT) を使用するプロジェクトに取り組んでいます。違いはあります。EXT GWT は、JavaScript ライブラリである ExtJS を作成した会社によって実際に作成されたものです。GWT EXT は、ExtJS ライブラリの GWT ラッパーです。GXT はネイティブ GWT です。

いずれにしても、GXT はまだ未熟で、GWT EXT にあるような強固なコミュニティが欠けています。ただし、GXT はネイティブ GWT であり、ExtJS を作成した会社によって実際に開発されているため、将来は GXT にあります。ExtJS ライブラリのライセンスが変更されたため、GWT EXT は多少機能不全になり、GWT EXT の開発が遅れました。

全体として、GWT/GXT は Web アプリケーションを開発するための優れたソリューションだと思います。私は実際、開発用のホストモードがとても気に入っています。ホストモードを使用すると、作業が迅速かつ簡単になります。コードをデバッグできるという利点もあります。JUnit を使用した単体テストも非常に堅牢です。エンタープライズアプリケーションをテストするのに十分成熟していると感じられる、優れた JavaScript 単体テストフレームワークをまだ見たことがありません。

GWT EXT の詳細については、次を参照してください。http://gwt-ext.com/

EXT GWT (GXT) の詳細については、次を参照してください。http://extjs.com/products/gxt/

簡単に克服できなかった大きな落とし穴はありません。ホストモードを頻繁に使用します。GWT-ext を使用しているため、すぐに使える外観を微調整する場合を除き、CSS を自分で触る必要はほとんどありません。

私のお勧めは、機能が近いライブラリウィジェットではなく、GWT の「ネイティブ」ウィジェットを使用することです。

検索エンジンのインデックス作成に関して:はい、サイトには通常はナビゲート可能な URL がありません (通常の Web サイトの要素にウィジェットを追加するだけでない限り)。ただし、履歴の戻る/進む機能を実行することはできます。

少し前のプロジェクトで GWT と GWT-ext を一緒に使用しました。Web 開発の経験は非常にスムーズであることがわかりましたが、私からのアドバイスは次のとおりです。

GWT ネイティブウィジェットと EXT ウィジェットを混合しないでください。通常、名前は同じなので (GWT.Button または GWText.Button?)、非常に混乱します。

コードを本当に複雑にしたことよりもコードを本当に複雑にしたことの1つは、a）動的に更新可能なパネルが欲しかったということでしたb）cascadable

GWT ネイティブパネルは動的であり、Ext パネルはカスケード可能です。解決？GWTExt パネルをラップする GWT.VerticalPanel...混沌。:)

でもまあ、それはうまくいきます。;)

ykagano さんのコメントに続きますが、最大の欠点は MVC で V を失うことです。真の ui クラスを残りのクライアント側コードから分離することはできますが、グラフィック/Web デザイナーによって生成された HTML ページを簡単に使用することはできません。つまり、開発者が HTML を Java に変換する必要があります。

wysiwyg ui エディターを入手すると、時間を大幅に節約できます。GWTデザイナーを使用しています。

GWT の最大の利点は、クロスブラウザの問題を忘れられることです。100％ではありませんが、ほぼすべての痛みを取り除きます。ホストモードデバッグの利点と組み合わせると (Firebug は優れていますが Java デバッガーと同じではありません)、開発者は複雑な Ajax アプリを生成する際に大きな利点を得ることができます。

ああ、特に gzip フィルターを使用する場合、実行時も高速です。

少し話が逸れましたが、継続的な問題が発生した場合には、irc の #gwt チャネルが非常に役立ちます。

GWT は非常に単純で直感的です。

特に UIBinder のリリースにより、GWT ウィジェットを XML でレイアウトし、その後 Java でコードビハインドできるようになりました。

そのため、他の Ajax や Flash 設計ツール、Silverlight などを使用したことがある場合、GWT は非常に簡単に習得できます。

落とし穴ではないにしても、大きなハードルは GWT RPC です。GWT を使用するまさにその理由は、GWT 非同期 RPC のためです。それ以外の場合は、CSS に頼ってページをフォーマットしてみてはいかがでしょうか?

GWT RPC は、サーバーがページを更新せずにサーバー上のデータを更新できるようにする要素です。これは、株価パフォーマンスの監視 (または米国の現在の国家および公的債務、または秒までに世界中で中絶された胎児の数) などのページでは絶対的な要件です。

GWT RPC を理解するには多少の努力が必要ですが、数時間もあればすべてが明らかになるはずです。

さらに、GWT RPC を学ぶために少し努力した後、最終的に、次の場合を除き、JSP を RPC のサービスコンポーネントとして使用できないことがわかりました。私のブログには、JSP を GWT RPC サービサーとして使用する方法について、8 部構成 (だと思う) シリーズがあります。しかし、あなたは答えを求めているのではなく、問題だけを求めているので、私のブログを宣伝するのはやめておきます。

それで。私は、GWT を使用する上での最悪の障害や落とし穴は、GWT 非同期 RPC を適切にデプロイする方法と、JSP サービサーを使用できるようにする方法を見つけることだと強く信じています。

私たちは、GWT コードベースと、Web デザイナーから入手した HTML Web テンプレート (GWT で管理したい特定の div ID を持つ静的 HTML ページ) を結合するのに非常に苦労しました。少なくとも私たちがそれを使用していた頃は、GWT でコーディングされていない Web サイトの部分と GWT を統合することができませんでした。最終的には機能するようになりましたが、それは大規模なハッキングでした。

サービスインターフェイスごとに記述する必要がある Async インターフェイスは、GWT コンパイラーによって自動的に生成されたものと似ています。
大規模なプロジェクトではコンパイル時間が長くなる

ただし、大規模な JavaScript プロジェクトの場合はこれが最良の選択です

GWT 2.4 では前述の問題の多くが修正されており、優れたウィジェットライブラリがベータ版としてリリースされました (Ext GWT 3.0.4、別名 GWT 3.0.4)。GXT) は、JS ライブラリのラッパーではなく、完全に GWT で書かれています。

残っている痛み：

CSS3 セレクターのサポートがないため、場合によっては「literal()」を使用して回避できます。
CSS3 や最新のブラウザイベントのサポートの欠如 遷移終了.
Java Calendar クラスのサポートの欠如 (何年も後)。
JUnit4 サポートの欠如 (5 年以上)。
Google GWT チームからの明確なロードマップとリリーススケジュールの欠如。

GWT2.4に関しては、 Firefoxを使用する GWT をデバッグするときは、Chrome を使用するよりもはるかに高速です。Firefox のみを使用する場合は、次の行を プロジェクト.gwt.xml ファイル

<set-property name="user.agent" value="gecko1_8" />

また、Eclipse を使用している場合は、引数 -> VM 引数に以下を追加します。

-Xmx512m -XX:MaxPermSize=1024m -XX:PermSize=1024m

サーバーとクライアントを分割し、引数 -> プログラム引数で以下を使用できます。-codeServerPort 9997 -startupUrl http://あなたのサーバー/プロジェクト -noserver

また、変更のたびにサーバーを更新しないようにするには、JRebel を使用します。http://zeroturnaround.com/blog/how-to-rock-out-with-jrebel-and-google-web-toolkit-gwt/そして、これがライブデモですhttp://www.youtube.com/watch?feature=player_embedded&v=4JGGFCzspaY

大きな落とし穴の 1 つは、特定の CSS スタイルを使用できるようにするために、最終的に HTML 要素となる要素に ID を明示的に割り当てる必要がある場合があることです。例えば：GWT TabPanel は、tabPanel の tabBar に ID が割り当てられており、その elementId で :hover を指定した場合にのみ、tabBarItems 上で :hover を実行します。

他のことについて書きました GWTのデメリット他の場所にありますが、それらはすでにrustyshelfsの回答でカバーされています:)。

私は最近 GWT に関して多くの作業を行ってきましたが、これが私が言わなければならないことです。

CSS のスタイル設定が難しい場合は、IE では IE 開発者ツールを使用し、Firefox では Firebug を使用して、何が起こっているのかを正確に把握すると、どの CSS を変更する必要があるかが明確にわかります。
トリックを使用して Google にインデックスしてもらうことができます。とても有名なサイトが、 http://examples.roughian.com/ Googleで評価をチェックしてください。それほど有名ではないサイトは、 www.salvin.in (それについて言及せずにはいられませんでした)、私はそれを言葉に最適化しました:salvin ホームページ (これら 3 つの単語を Google で検索してください)

私は GWT-EXT についてはあまり知りませんが、サードパーティのライブラリを含める必要はないと考えています。

あなたの決定が幸運を祈ります:)

GWT は機能検出ではなくブラウザスニッフィングを実行するため、アプリケーションは一部のブラウザ (特に新しいブラウザ) では動作しません。

この問題に関する参考文献は次のとおりです。

特徴検出に関する参考資料は次のとおりです。

から抜粋 JavaScript フレームワークの比較 - ウィキペディア

GWT チームは、昨年リリースした GWT 2.7 に多くの大幅な改善を加えました。GWT の大きな弱点の 1 つは、GWT 2.6 以前ではコンパイルに時間がかかることでした。これはなくなりました。GWT には超高速で変更のみをコンパイルするインクリメンタルコンパイルがありません。

GWT 2.7 には (ソース):

増分ビルドはわずか数秒で完了
よりコンパクトでより正確なソースマップ
GSSのサポート
JSInterop
優れた JavaScript パフォーマンス
コードサイズの縮小

信頼できる事実を得る最良の方法は、 GWT調査. 。GWT に関する最大の問題の 1 つは常にコンパイル時間が長いことです。幸いなことに、それは非常に急速に改善されているため、近い将来には重大な問題にはならないでしょう。もう 1 つの落とし穴は、Java がより複雑な言語であり、悪いプログラマーがあらゆる段階で抵抗するため、GWT が大幅に複雑になることです。さらに、コンパイルするとレイヤーが追加されます。たとえば、js 相互運用には小さな定型文が必要です。根本的な問題は、GWT が単純になるように設計されていないことです。これは非常に複雑な Web アプリ向けにゼロから設計されており、コミュニティ全体が一貫して簡単なコーディングよりもパフォーマンス、コード品質、アーキテクチャなどを優先しています。
GWT ではいつでも js を使用できるので、GWT に問題がある場合は js の使用を検討してください。結局のところ、GWT は js なので、js でできることはすべて GWT で実行できます。実際、ほとんどの GWT プロジェクトは js を使用します。問題は、GWT が大幅に複雑であることです。それでも、場合によっては、さらに複雑にする価値があります。

GWT 3.0 では大幅な改善がもたらされることは注目に値します。

RPC サービスオブジェクトを再利用します。
競合状態が発生し、アプリがハングしたような症状が発生します。

私が1に出くわした落とし穴。superdev モードでは動作が異なります。例えば。Someclass.class.getName() は Superdev モードではまったく問題なく動作し、クラスの完全修飾名を返します。生産モードでは、これは機能しません。

addWidget(widget) はウィジェットのremovefromparent()を呼び出します。

GWT はテクノロジーの傑作です。これは、クライアントとサーバーのプログラミングを統合して、1 つの一貫したアプリケーションを作成します。これは、ソフトウェアが「階層化」される前に記述された方法であり、ソフトウェアが記述されるべき方法でもあります。これにより、さまざまなスキルセット、チームメンバー間のコミュニケーションの誤り、そして一般に Web デザインフェーズ全体が排除されます。芸術性とプログラミングの両方。そしてそれはモバイルに最も近いものです。アンドロイド開発。実際、GWT は HTML だけでなく、さまざまなネイティブ UI を生成するように設計されています。ただし、このような分離を確実に行うには、つまり内部レイヤーのプレゼンテーションに依存しないようにするには、多大な規律が必要です。

避けるべき最初の間違いは、EXT-GWT (別名 GXT) や SmartGWT などのサードパーティ拡張機能を使用することです。これは私が気づくのに 4 年かかりました。独自のスタイルに投資する代わりに、かなりデスクトップ風のウィジェットを使い始めたいと思うのは非常に魅力的ですが、最終的にうんざりするまで、SmartGWT でどれだけの問題が発生したかわかりません。つまり、コアの GWT 機能セットを特定の (かなり古い) レベルで凍結し、その上に構築します。また、パフォーマンスの低下、大量のバグ、特にモバイルデバイスでの互換性機能は言うまでもなく、彫りの深いデスクトップのルックアンドフィールが最近では愚かに見えることにも留意してください。ネイティブのブラウザコントロールにできるだけ近い状態を保ちたいと考えています。ドロップダウンは、カスタムペイントされたコントロールではなく、ネイティブの <select> 要素としてレンダリングされます。

モバイルトレンドのおかげで、UX 全体がよりシンプルかつフラットになっているため、シャープな外観のアプリケーションをスタイルするために多くのことを行う必要はありません。ただし、「3D」の外観が必要な場合は、グラデーションもあります。CSS3 ではすべてが簡単になり、GWT では生の CSS とは異なり、エレガントなオブジェクト指向の方法で CSS3 がラップされます。したがって、GWT ショーケースでかなり醜いベアボーンコントロールを見て落胆しないでください。GWT チームは、スタイリングは開発者の仕事であるため、意図的に提供しませんでした。

残りは、美しく簡潔な API を備えた、厳密に型指定された Java による従来のブラウザプログラミングです。ただし、もちろん、コードはブラウザ内で実行されるため、すべての呼び出しが非同期であることを忘れないでください。ループ内で GWT-RPC メソッドを呼び出すことはできません (リストを作成するため)。この状況に陥った場合は、再帰的にチェーンする必要があります。

GWT-RPC を使用しないなど、自称「アンチパターン」がいくつかあります。これまでのところ私にとっては良いことです:10年間。シンプルさが重要です。コードの優雅さと保守性のために、わずかなパフォーマンスを犠牲にすることは一秒たりとも考えません。さらに、ボトルネックとなるのはデータベースではありません。もちろん、クライアントに送信するデータの量には注意してください。

また、既存のガジェットを見つけられない場合やスタイルを設定できない場合、つまりリッチ HTML5 要素セットを読み取って、いつでもサードパーティ製のガジェットをラップすることができます。人気のjQuery FullCalendarを使ってやってみました。まったくロケット科学ではありません。Google マップや Google チャートなどの他のすべてのものには、半公式の GWT ラッパーがあります。

GWTは完璧です。それが十分な愛を受けていない唯一の理由は、今でも業界に影響を与えている初期のインターネット採用者がコンピューターサイエンスやオブジェクト指向言語の出身で、それらを高く評価していないためです。彼らは芸術的 (Photoshop/WordPress) またはネットワーク (Perl/Python) のバックグラウンドを持っています。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow