最高のGWTウィジェットライブラリ？
そこにあるすべてのGWT達人への質問-そこにある最高のGWTウィジェットライブラリはどれですか？なぜ？
回答に基づいたリスト：
- デフォルト
- Sencha GXT
- スマートGWT
- Vaadin
- GWT-Bootstrap
- GwtBootstrap
- Rocket GWT （非アクティブ）
- 畳 （非アクティブ）
- ErraiFramework
- GWTMaterialDesign
Инаконец-новоепоколениеоснованноена JsInterop ：
これらのライブラリに縛られないでください。 Vanilla GWTを使用して、プロジェクトの構造を作成します。特に、MVPパターンとイベントバスを使用します。 GWTを使用してクライアントアプリケーションを最適に設計する方法については、Googleの記事をご覧ください： Building MVP apps
その後、これらのライブラリの任意のウィジェット（テーブル、コンボボックス、日付ピッカーなど）を使用して、プロジェクトに組み込むことができます。 Vanilla GWTでそれを行う方法が見当たらない場合にのみ、拡張コンポーネントを使用してください。この方法では、デモアプリケーションに表示されず、多くのバグが含まれており、サポートが不十分な場合でも、常に苦労するこれらのライブラリに縛られません。
ウィジェットの検索方法は次の順序に従う必要があります。
- 最初にGWTインキュベーターをチェックして、探しているものがあるかどうかを確認します。 http://code.google.com/p/google-web-toolkit-incubator/
- 次に、「クーラー」を探している場合は、GWT Mosaicを確認してください http://code.google.com/p/gwt-mosaic/
他のライブラリに注意して、私は彼らと仕事をしました（そして、まだ悪夢を抱えています）。
「最高」の意味に依存します。一番よく見える？最高のAPI？独自のカスタムニーズに拡張するのに最適ですか？
たとえば、私はアプリケーションで使用するテーブルクラスを評価していました。 GWT-Extを使用してきましたが、パフォーマンスの問題が多くあり、必要なサイズにテーブルをサイズ変更することは非常に困難です。 GWT-Mosaic に近づきましたが、代わりに GWT Incubator でウィジェットを構築することにしました。
それで、なぜ私はこの選択をしたのですか？優れたWordの手荷物が不足しているため、世の中にはあまりにも多くのライブラリがあります。いくつかのMVCフレームワーク（コードベースの残りの部分と完全に互換性がない可能性があります）に丸ごと飛び込む必要があるか、誰かの新しい複雑なレイアウトシステムを採用するか、できないという事実に耐えなければなりません本当にコードをデバッグします（JSNIラッパーだけのため）。
誤解しないでください、GWTインキュベーターは完璧ではありません...そこにあるウィジェットは流動的です。私の場合、これが最良の選択でした。それは私に良いものを提供します（しかし、完璧ではありません）。
- API
- 拡張性
- ルックアンドフィール（まあ、これはちょっと弱いですが、それがCSSの目的です）
だから...答えは（私にとって）次の組み合わせです：
- GWTウィジェットのストック（カスタムスタイルのlotsを使用）
- GWTインキュベーターテーブル
- いくつかの自家製ウィジェット
（追加する必要があります：私が言及している「手荷物」は、必ずしも必要ではありません悪いことではありません。 、それはあなたの仕事を成し遂げるために何が必要か、そしてあなたのアプリケーションがどれほど見栄えが良いかについての水準を上げることができます。
このコンポーネントライブラリを参照してください GWT Bootstrap これは、Twitter Bootstrapのgwtでの実装です。
GWTだけでも非常に優れたライブラリです。
上記のすべてを使用したわけではありませんが、 Ext GWT を推奨できます。
私はバニラGWTが好きです。他のAPIのいくつかはきれいに見え、そのショーケースは本当にウィジェットを誇示しますが、パフォーマンスは最高ではないことが常にわかります。アプリケーションの動作が遅いと思うと嫌いです。
言及されたライブラリのほとんどはオープンソースではなく、さらに悪いことです。JavaScriptライブラリの最上部にある単なるラッパーです。 GWTの威力は、アプリケーションがさまざまなブラウザーで動作するという事実にあります（具体的には「大きな」ブラウザー用のコード生成のため）。これらのJavaScriptベースのライブラリは、多くの問題を引き起こす可能性があります。
これまでのところ、jgindin GWT IncubatorとGWT Mosaicが最高だと思います。
「最高」とは言いませんが、最近仕事で GWT-Ext を使用しています。長所と短所があります。
長所：
- セットアップと使用が比較的簡単
- その背後にあるまともなサイズのコミュニティ
- オンラインのサンプルがたくさんあり、すべてに付属のコードがあります
- 幅広い機能をカバーする適切なウィジェットの選択
短所：
- データの形式と構造について、対応できない可能性があると仮定します
- ライブラリは単なるJSNIラッパーであるため、デバッグと拡張が困難になります
- ライブラリの将来のサポートと開発は不確実です
- いくつかの迷惑なクロスブラウザの問題がまだ存在します（特にレイアウトの場合）
- 彼らのフォーラムの検索機能は本質的に役に立たない。 （これは私の大きなペットの欲求になりつつあります> _ <）
それらのいずれも使用しないでください！大規模なアプリケーションの開発を計画している場合は、MVPパターンの使用を検討する必要があります。最適な実装は MVP4G フレームワークであり、すぐに使用できるGWTコード分割をサポートしています。たくさんの素晴らしい例がありますが、まずは始めてください。最も価値のあるものはMvp4GModulesです。
新しいものを追加します： GET-Bootstrap :)
現在、安定版リリースはありませんが、すぐにリリースされます。
私の経験から、サードパーティのライブラリには常に多くの問題があることがわかります。最良の方法-よく知られ、よく作られた技術自体に加えて、独自のコンポーネントを使用することです。それらの記述と保守には時間がかかる場合がありますが、TCOは常に低いレベルです。
サードパーティのライブラリは、多くの場合、計画を予期せずに中断する可能性があります。そして、問題の原因を見つけて修正することは困難です。
したがって、単純なGWTを使用することをお勧めします。
ウィジェットをそのまま使用したい場合はSmartGWTで問題ないと思いますが、 Gxt Scheduler で行うようにウィジェットを拡張または変更したい場合は、Ext-GWTはより良い選択。
私にとってEXT-GWT（別名GXT）は現在利用可能な最高のライブラリであり、6か月のプロジェクトで使用しています。また、グリッド、ツリーなどの多くの定義済みコンポーネントで非常に役立ちます。
gwt-mosaicのユーザーグループはあまり活発ではないようで、wikiスニペット以外にユーザーマニュアルを見つけることができませんでした。 gwt-mosaicは、2つの興味深いツールを紹介してくれました。
1）gwt-mosaicには、アプリのJSパーツ（RPCハンドラー、ウィジェットコールバック、ウィジェットセッター）のパブリッシュ/サブスクライブツールであるTibcoのPageBusのラッパーが含まれています。これは、gwtのイベントバスに代わるものです。
2）gwt-mosaicは、データをウィジェットにバインドし、ウィジェットを検証するためにBeans Binding（http://code.google.com/p/gwt-beans-binding/）の使用を推奨しています。
smartgwtは、完全な機能セットとサポートのために安くはありません。 jarは、使用しないテーマファイルを削除しない限り、appengineには大きすぎます。サーバー側にもエンジニアリングを投資します。
Ext-gwtが遅く、JSファイルが大きいと聞きました。
Gwtウィジェットのインキュベーターは非推奨のようです。デラックスグリッドは新しいgwtでリリースされると思います。
ルックアンドフィール、バインディング、および検証の標準がないため、ウィジェットライブラリの相互運用性が妨げられています。
間違いなくSmartGWTではありません。それらのフレームワークは肥大化しており、中途半端な性質を持っています。彼らには100万のウィジェットがありますが、あなたのプロジェクトのためにそれらを動作させることは簡単ではありません。データソースは、データを非常に大きな方法で管理するプロセスを複雑にします。たとえば、データソースのデータにアクセスするには、fecthを使用して頻繁に検査する必要があります。結果をキャッシュすることはできますが、結果を調べるのは必ずしも簡単ではありません。
RPCは別の弱くて複雑な領域です。ドキュメントとフォーラムに矛盾する情報があります。ドキュメントにはdsの一部としてカスタム操作を使用することはめったにないと書かれていますが、フォーラムでは完全に問題がないことがわかります。これらのツールを効果的に使用することを学ぶことは、最高の日々の上り坂です。
彼らは製品を過剰販売します。たとえば、charting/analyticsパッケージにはグラフが含まれています...しかし、これらのグラフは負の値を表示したり、軸ラベルを意味のある方法で操作したりすることはできません。そして、彼らはフォーラムでこの質問に「はい、どうした」態度で率直に答えます。 「それが私たちのセールスポイントの1つであるにもかかわらず、それを3.0xに追加する予定はありません。ロードマップ上にあります。」彼らが私にパッケージを売ったとき、彼らは私が負の値を表示することができなかったと決して述べませんでした。本当に？どのグラフが負の値を表示できる必要はないでしょうか？不幸な同形顧客の数を描いているのは1つだけです。
これらの人から離れて、競合他社のサイト（ExtJS、JQueryなど）に行きましょう。いくつかのプロジェクトがありますが、これらのプロジェクトは実際に成果を上げており、実際に優れたソリューションを提供しています。
この製品を評価する場合は十分に注意してください。見た目はいいですが、それを使用するプロジェクトに約2週間かかります。ウィジェットは中途半端で、データソースは非常に複雑です。フォーラムのサポートにお金を払ったからといって、実際にスナイド以外の何かを得ることを意味するわけではありません。彼らは一般的に非常に慢ではなかった。
幸運を祈ります。開発時間と保守性を重視する場合は、この製品を避けてください。ああ、最後に一つ。 WebサイトでMVCの例を見てください。ラベルが「MVC」を読み取ること以外は、文字通りMVCとは関係ありません。彼らはあなたにそのようなフレームワークは経験の浅い開発者向けであり、そのような概念は実際のプログラミングには場所がないことをあなたに納得させようとします。
少数のウィジェットのみが必要な場合は、独自のウィジェットを作成します。上記のライブラリからいくつかの概念をコピーして貼り付けることができます。しかし、それらはすべてどちらか一方を欠いています。私はそれらのほとんどで遊んで、すべてを放棄しました。
現在、 GWT Mosaic ウィジェットが気に入っています。 ext-JSを使用し、過去に独自のウィジェットを展開しました。 ext-JSライセンスとバルクが問題でした。自分で転がすことは私たちがやりたいことではありません。 Mosaicは私たちに幸せな中間地点を与えてくれます。プロジェクトが成熟するにつれて、これはさらに幸せな中間地点になると思います。
Googleのデフォルトライブラリは最も強力なライブラリです。
Ext GWT は、ベルとホイッスルを追加しますが、それ以外はGoogleに似ています。
smartGWTは遅く、例が不足しており、基本的な質問でさえ答えを見つけることは非常に困難です。つまり、このフォーラムですべての未回答の質問を参照してください。 smartgwtをダンプしています。
私たちは2年以上gwtプロジェクトを行ってきましたが、デフォルトのウィジェットに固執しています。デフォルトのものまたは独自のウィジェット拡張を自動入力するために、独自のオープンソースライブラリを作成しました。それを確認してください、それは gwt-jet と呼ばれます。大規模な実稼働環境で使用するため、非常によくテストされており、時間をかけて安全に成長することを願っています。
GWTを1年間使用しています。多くの研究の結果、ウィジェットライブラリとしてGWT Mosaicを決定しました。MosaicはPagingScrollTableなどのGWTインキュベーターコンポーネントの一部を使用します。しかし、コンボボックスとテーブルの機能は十分ではありません。これらのコンポーネントを拡張して、必要な機能を追加しました。
SpiffyUIをご覧ください： www.spiffyui.org
これは単なるウィジェットライブラリではなく、複雑なUI/UX GWTフレームワークです。
2つのEXT の長所と短所の比較。
GWT Portlets を使用して、大規模なHRポータルといくつかの小規模なアプリケーションを構築しました。このプロジェクトの焦点は、ウィジェットのコレクションの構築ではなく、単純なプログラミングモデルの作成です。
ウェブサイトから：
GWT Portletsは、GWT（Google Web Toolkit）アプリケーションを構築するための無料のオープンソースWebフレームワークです。非常にシンプルで生産的でありながら強力なプログラミングモデルを定義して、見栄えの良いモジュール式GWTアプリケーションを構築します。
プログラミングモデルは、ポータルサーバー（Liferay、JBoss Portalなど）向けのJSR168ポートレットの記述に多少似ています。 「ポータル」は、GWT Portletsフレームワークをライブラリとして使用して構築されたアプリケーションです。アプリケーション機能は、それぞれがオプションのサーバー側DataProviderを備えた疎結合ポートレットとして開発されます。
2つの重要なこと、そしてほとんどのライブラリが見落としていることは、ユニットテストとデバッグです。 GWTが輝く場所です。 Vanilla jsに基づいたライブラリを使用する場合、プロジェクトの単体テストとデバッグの機能を提供します。 GWT開発者は、これらの点を考慮し、js依存性がないか最小限のライブラリを使用する必要があります。