27

私は数日後に smartGWT プロジェクトの作業を開始します。あなたがどのような経験をしたか知りたいです。これが smartGWT や GWT のバッシング、またはフリースタイルの議論になるのを避けるために、議論のヒントをいくつか提供します。

  • 提供されたウィジェットはうまく統合されていると思いますか? 特に見逃しているウィジェットはありますか?
  • アプリケーションを設計する際に、フレームワークが原因で問題が発生したことはありますか?
  • データソースの統合は、smartClient チームが主張するほど有用ですか?
  • smartGWT アプリケーションを永続化するためにどのような方法を使用していますか? 例: Hibernate と smartGWT はどの程度うまく機能しますか?

指摘する価値があると思われるものは何でも自由に追加してください。

4

7 に答える 7

21

すでに回答をお持ちだと思いますが、決定に影響を与える可能性のあるコメントをいくつか追加したいと思います。

長所：

  • SmartGWT は、見つけることができる最も包括的な LGPL GWT ベースのウィジェット ライブラリです。したがって、GPL の苦痛を気にするなら、これはあなたのものです
  • 総合ショーケース。
  • 本当に良いパフォーマンスです (ショーケースをチェックしてください)。
  • フォーラムでの非常に活発なコミュニティ。
  • SmartGWT 拡張機能は、もう 1 つの重要なプロジェクトです。たとえば、GWT-RPC ベースの通信をサポートしていますが、これは SmartGWT だけでは可能ではありません (独自の統合を実装しない限り)。
  • SmartGWT 関係者による急速な開発ペース。SmartGWT プロジェクトが登場してからのリリース数を数えてみてください。

短所：

  • ショーケースのほかに、何かがどのように機能するかを理解する唯一の方法は、フォーラムで質問することだと感じることがあります。これは、知識ベースの拡散につながります。コミュニティベースのウィキが望ましいでしょう。
  • アプリケーションで使用しなければならない大量の静的ファイル (有名な 'sc' ディレクトリ) は、バックエンドが GAE にある場合に問題を引き起こす可能性があります (1000 ファイルの制限のため)。
于 2009-05-25T17:16:07.203 に答える
14

前回のプロジェクトではSmartGWTを使用しました（期間：6か月）。以下は私の個人的な意見です。

ウィジェットは本当に素晴らしいです！ドキュメントとAPIは冗長です。再びクライアントサイドを使用します。

サーバー側の統合は機能しますが、開発時間を節約することはできませんでした。代わりに、回避策を見つける必要がある多くの問題がありました。また、新しいAPIがあるため、SmartGWT APIを学ぶために多くの時間を費やして、他の開発者がプロ​​ジェクトを維持することはできません。

いくつかの短所：

  • HibernateとGWT-RPCまたはRESTを使用する代わりに、まったく新しいAPIを学習する必要があります。

  • データ統合は自動的に行われます、それは本当です。ただし、いくつかの（少しでも）変更が必要な場合は、HibernateまたはJDOの場合と同様にXMLマッピングファイルを作成する必要があります。したがって、メリットはなくなります。

  • フォーラムのサポートは悪いです：あなたはほとんどすべての投稿された質問への答えを得る。しかし、その答えはしばしば役に立ちません。彼らはあなたに「なぜあなたはそれをしたいのか」などのことを尋ねます。または、「ツールを使用してXYZを実行する」と3回言いますが、この提案は機能しないと何度も言いました。質問に対するいくつかの回答の後、最終的な回答は「トレーニングが必要です。サポートを購入してください」です。

  • 商用サポートは高額になります（SmartGWTライセンスとほぼ同じくらいの費用がかかります）。

SmartGWTのサーバー側統合を再び使用することはおそらくないでしょう。

私のブログで、賛否両論で私の「学んだ教訓」をすべて読むことができます。

http://www.kai-waehner.de/blog/2010/12/11/lessons-learned-smartgwt-2-3-component-library-for-google-web-toolkit-gwt/

よろしく、KaiWähner

于 2010-12-11T09:58:02.250 に答える
8

提供されたウィジェットはうまく統合されていると思いますか? 特に見逃しているウィジェットはありますか?

必要なすべてを提供できる単一のフレームワークはありません。ウィジェットはかなり拡張可能です。

データソースの統合は、smartClient チームが主張するほど有用ですか?

データ (JSON/XML) はサーブレット サービスによって提供され、ウィジェットによって理解されます。

smartGWT アプリケーションを永続化するためにどのような方法を使用していますか? 例: Hibernate と smartGWT はどの程度うまく機能しますか?

GWT のバックエンド サーブレット サービスでは、Java の任意の永続レイヤーを使用してストア内のデータを永続化できます。Hibernate は、通常の Java アプリと同じように使用できます。

于 2009-05-18T09:05:49.037 に答える
6
提供されたウィジェットはうまく統合されていると思いますか? 特に見逃しているウィジェットはありますか?

はい。ウィジェットには一貫した API があり、連携してうまく機能します。

データソースの統合は、smartClient チームが主張するほど有用ですか?

この IMO は、彼らの最も強力な機能の 1 つです。Datasource API の使用を開始すると、完全に機能する CRUD 画面を取得するために必要なコードがいかに少ないかがわかります。

smartGWT アプリケーションを永続化するためにどのような方法を使用していますか? 例: Hibernate と smartGWT はどの程度うまく機能しますか?

Hibernate は SmartGWT EE バージョンですぐに使用できます。Gleadを使用したLGPLバージョンではうまく機能します

于 2009-05-19T13:34:02.007 に答える
4

SmartGWTにはたくさんの素晴らしいウィジェットがあると思いますが、しかし、莫大な価格があります。単純なSmartGWTベースのプロジェクトを作成し、ページによって読み込まれるファイルの数を監視します。それは、GWTのようなものの理想に完全に反していると思います。SmartGWTは締め切りのある人にとってはかなり良いオプションかもしれませんが、生のパフォーマンスが必要な場合は、それを避けてください。HTTPリクエストの数は、単にアプリケーションを強制終了します。

于 2009-12-28T10:23:27.960 に答える
2

Wicketの問題について言及した上記のポスターの対位法と同様に、SmartClientフォーラム（forums.smartclient.com）には、SmartGWTを他のさまざまなテクノロジーと統合することに成功したという報告があります。このポスターの問題は、1）JavaScriptの不良を引き起こすGWTのバグ、2）SmartGWTとWicket間のCSSの名前の競合、おそらくどちらのフレームワークのせいでもないように聞こえます。SmartGWTのすべてのスタイル名は、スキニングシステムを介して名前を変更し、そのような競合を解決できます。

于 2009-06-10T23:37:31.723 に答える