smartGWTの短所と長所
数日でsmartGWTプロジェクトの作業を始めていますが、どのような経験があったのか知りたいです。これをsmartGWTやGWTのバッシング、またはフリースタイルのディスカッションにすることを避けるために、ディスカッションへのいくつかの指針を提供します。
- 提供されているウィジェットはうまく統合されていると思いますか？特に見逃しているウィジェットはありますか？
- フレームワークが原因でアプリケーションを設計するときに問題が発生しましたか？
- データソースの統合は、smartClientチームが主張するのと同じくらい便利ですか？
- SmartGWTアプリケーションを永続化するためにどのような方法を使用していますか？例えばHibernateとsmartGWTは互いにどの程度うまく機能しますか？
指摘する価値があると思われるものは何でも自由に追加してください。
あなたはすでにあなたの答えを持っていると思いますが、あなたの決定に影響を与えるかもしれないいくつかのコメントを追加したいと思います：
長所：
- SmartGWTはtheあなたが見つけることができる最も包括的なLGPLGWTベースのウィジェットライブラリです。したがって、GPLの痛みを気にするなら、これはあなたのものです
- 包括的なショーケース。
- 本当に良いパフォーマンスです（ショーケースをチェックしてください）。
- フォーラムの非常に活発なコミュニティ。
- SmartGWT拡張機能はもう1つの重要なプロジェクトです。たとえば、GWT-RPCベースの通信をサポートしていますが、これはSmartGWTでのみ可能ではありません（独自の統合を実装しない限り）。
- SmartGWTの連中からの急速な開発ペース。 SmartGWTプロジェクトが登場してからのリリース数を数えるだけです。
短所：
- ショーケースのほかに、何かがどのように機能するかを理解する唯一の方法は、フォーラムで質問することだと感じることがあります。これは知識ベースの普及につながります。コミュニティベースのウィキが望ましいでしょう。
- アプリケーションで使用する必要のある大量の静的ファイル（有名な「sc」ディレクトリ）。これは、バックエンドがGAEにある場合に問題を引き起こす可能性があります（1000ファイルの制限のため）。
前回のプロジェクトではSmartGWTを使用しました（期間：6か月）。以下は私の個人的な意見です。
ウィジェットは本当に素晴らしいです！ドキュメントとAPIは冗長です。再びクライアントサイドを使用します。
サーバー側の統合は機能しますが、開発時間を節約することはできませんでした。代わりに、回避策を見つけなければならないという多くの問題がありました。また、新しいAPIがあるため、SmartGWT APIを学習するために多くの時間を費やして、他の開発者がプロジェクトを維持することはできません。
いくつかの短所：
HibernateとGWT-RPCまたはRESTを使用する代わりに、まったく新しいAPIを学ぶ必要があります。
データ統合は自動的に行われます、それは本当です。ただし、いくつかの（少しでも）変更が必要な場合は、HibernateまたはJDOと同様にXMLマッピングファイルを作成する必要があります。したがって、メリットはなくなります。
フォーラムのサポートは悪いです：投稿されたほとんどすべての質問に対する回答が得られます。しかし、その答えはしばしば役に立ちません。彼らはあなたに「なぜあなたはそれをしたいのか」などのことを尋ねます。または、「ツールを使用してXYZを実行する」と3回言いますが、この提案は機能しないと何度も言いました。質問に対するいくつかの回答の後、最終的な回答は「トレーニングが必要です。サポートを購入してください」です。
商用サポートは高額になります（SmartGWTライセンスとほぼ同じくらいの費用がかかります）。
SmartGWTのサーバー側統合を再び使用することはおそらくないでしょう。
私のブログで、賛否両論で私の「学んだ教訓」をすべて読むことができます。
よろしくお願いいたします。KaiWähner
提供されているウィジェットはうまく統合されていると思いますか？特に見逃しているウィジェットはありますか？
見逃したウィジェットを作成することはできますが、必要なものすべてを提供できる単一のフレームワークはありません。ウィジェットはかなり拡張可能です。
データソースの統合は、smartClientチームが主張するのと同じくらい便利ですか？
データ（JSON/XML）はサーブレットサービスによって提供され、ウィジェットによって理解されます。
SmartGWTアプリケーションを永続化するためにどのような方法を使用していますか？例えばHibernateとsmartGWTは互いにどの程度うまく機能しますか？
GWTのバックエンドサーブレットサービスでは、Javaの永続レイヤーを使用して、ストア内のデータを永続化できます。 Hibernateは、通常のJavaアプリと同じように使用できます。
提供されているウィジェットはうまく統合されていると思いますか？特に見逃しているウィジェットはありますか？
はい。ウィジェットには一貫したAPIがあり、連携して機能します。
データソースの統合は、smartClientチームが主張するのと同じくらい便利ですか？
このIMOは、彼らの最も強力な機能の1つです。 Datasource APIの使用を開始すると、完全に機能するCRUD画面を取得するために必要なコードがいかに少ないかがわかります。
SmartGWTアプリケーションを永続化するためにどのような方法を使用していますか？例えばHibernateとsmartGWTは互いにどの程度うまく機能しますか？
Hibernateは、SmartGWTEEバージョンでそのまま動作します。 Gleadを使用したLGPLバージョンではうまく機能します
SmartGWTにはたくさんの素晴らしいウィジェットがあると思いますが、しかし、莫大な価格があります。単純なSmartGWTベースのプロジェクトを作成し、ページによって読み込まれるファイルの数を監視します。それは、GWTのようなものの理想に完全に反していると思います。 SmartGWTは締め切りのある人にとってはかなり良いオプションかもしれませんが、生のパフォーマンスが必要な場合は、それを避けてください。 HTTPリクエストの数は、単にアプリケーションを強制終了します。
- フレームワークが原因でアプリケーションを設計するときに問題が発生しましたか？
はい。 Google Eclipseプラグイン、SmartGWT、GWT 1.6.4、およびWicketを組み合わせると、gwtコンパイラーが不正なJavaScriptを出力していました。悪いjavascriptとは、webkitやFirefoxでは機能しないjavascripを意味します。 Eclipseプロジェクトから完全に削除してEclipseを再起動するまで、適切なJavaScriptを取得できませんでした。そのため、この組み合わせは機能せず、別のプロジェクトでSmartGWTピースを個別に作成することになりました。もう1つの問題は、スマートクライアントがCSSの意味でページ全体の制御を望んでいるように見えることです。そのため、スタイルが適切に分離されていなかったため、統合されたSmartGWTモジュールはすべて台無しになりました。あなたのマイレージは異なる場合があります。
個人的には、SmartGWTのみを使用し、すべてに使用する場合はすべて問題ない可能性がありますが、それを組み合わせてみると、私の結果は悲惨なものでした。だから、もう使いません。
Wicketの問題について言及した上記のポスターとは対照的に、SmartClientフォーラム（forums.smartclient.com）には、SmartGWTを他のさまざまなテクノロジーと統合することに成功したという報告があります。このポスターの問題は、1）悪いJavaScriptを引き起こすGWTのバグ、2）SmartGWTとWicketの間のCSSの名前の競合、おそらくどちらのフレームワークのせいでもないように聞こえます。 SmartGWTのすべてのスタイル名は、スキニングシステムを介して名前を変更し、そのような競合を解決できます。