7

次のフレームワークのリストから、リッチWebアプリケーションを開発するためにどのフレームワークを使用しますか。また、他のフレームワークよりもなぜそれを選択するのでしょうか。

Sproutcore GWT ExtJS GXT SmartGWT Dojo /DijitFlexカプチーノGrails

4

9 に答える 9

6

私は個人的にブラウザの不整合にうんざりしています。他の誰かが問題を解決した場合、私はそれを二度とやりたくない。だから私はカプチーノやqooxdooのようなフロントエンドにもっと興味を持っています。それらはゼロHTMLゼロCSSソリューションです。

于 2010-03-18T05:02:00.793 に答える
5

これらは、あなたが言及したフレームワークを使用した私の個人的な経験に基づいています。そうです、それは少し偏っています。したがって、他の人が何度も言っているように、あなたの要件を定義し、人々がここで提案したことに基づいて、どれがあなたの要件に合うと思いますか。

  • GWTは冗長すぎますが、多くのJava開発者はGWTをユニットテストでき、すべてJavaであるため、GWTを気に入っています。しかし、私はそれが単純ではないので、個人的には好きではありません。Javascriptで少し調整できると感じることもありますが、GWTでは数行のJavaコードで調整する必要があります。
  • GXTは最近GWTから遠すぎて、GXTにはGWTとはあまりにも異なる独自の方法があるため、物事を行うのが難しいことがわかります。複雑な要件が発生した場合、最終的にはプレーンGWTを実行することに戻ります。そして、ああ、彼らにいくつかの質問をしたときに私がいくつかの悪い経験をしたので、彼らの技術サポートもそれほど良くありません。
  • Ext-JSは単純なものに適しており、ルックアンドフィールは本当に洗練されています。しかし、物事がより複雑になると、あなたは自分が通り抜けて戦うことになります。GXTのテクニカルサポートは扱ってきましたが、ExtJSのテクニカルサポートは1社でも人が違うのであまり言えません。
  • フレックスは素晴らしいです、本当に素晴らしいです。しかし、これも単純なものには適しています。物事がより複雑になると、たくさんのアクションスクリプトを書くことになりますが、それはあまり楽しくありません。マルチメディアサポートのように、Javascriptでコーディングする必要がある場合は、箱から出してすぐに利用できるものがたくさんあります。そして、ああ、あなたが公開ウェブサイトのために書いているなら、あなたはあまり多くのユーザーが彼らのブラウザにフラッシュプラグインを持っていないことを考慮しなければなりません。
  • Grails、Grailsを使用してRIAアプリを実装する方法がわかりません。これは、Grailsが、前述のような独自のRIAフレームワークを追加する必要があるもう1つのMVCフレームワークであるためです。
于 2010-03-18T05:05:04.123 に答える
5

これは厳密には意見の問題です。答える人は誰でも個人的に好きなものを持っているので、誰からも決定的な答えを得ることができません。

あなた（またはあなたのチーム）の目的に最適なものを決定するのに十分な時間、それぞれを試してください。

そうは言っても、私はGWTが好きです。他の人はいつも私に同意しません。

私がGWTが好きな理由：

  • （一部の）クライアント側とサーバー側のコードを共有できます（サーバーがJavaで記述されている場合）
  • GWTを使用すると、多くの高度なパフォーマンス機能が非常に簡単になります（たとえば、JSの読み込みの延期、画像のスプライス、CSSの難読化など）。
  • プレイスのサードパーティサポートを備えた1ページのアプリに焦点を当てる（gwt-presenterライブラリを使用）
  • 完全な1ページのGWTアプリを作成するのと同じように、既存のWebページにGWTを追加するのも簡単です。
  • UiBinder宣言型のHTMLのような構文を使用してUIを記述できます。したくない場合は、SwingのようなUIを書くことに固執していません
  • ブラウザの非互換性は（ほとんど）GWTによって処理されます-Javaコードを記述するだけで、GWTはそれをコンパイルしてすべてのブラウザで動作します

GWTをあなたに適さないものにするかもしれないもの：

  • サーバーがすでにJava以外の何かで書かれている場合でも、GWTでUIを書くことはできますが、いくつかの優れた機能を失うことになります。
  • GWTを使用したコンパイル時間は重要なコストです-開発モードはこれを大幅に軽減しますが、それでも問題になることがあります
  • 他の人が述べているように、GWTはjQueryやExtJSのような単純なJavaScriptライブラリと比較して「冗長」と見なすことができます
于 2010-03-18T04:19:53.003 に答える
3

ExtGWTは私のプロジェクトでうまく機能しました。プレミアムサポートは良好です。

ただし、このプロジェクトは内部使用を目的としており、展開を1つのOS上の1つのブラウザーに制限することができ、ExtGWTのデフォルトの外観や動作を変更するための取り組みは行われていません。

完全にJava内で開発することは、機能が追加されたときにプロジェクトを管理しやすくするのに役立つため、重要な利点です。

于 2010-03-18T15:17:21.400 に答える
2

私は現在、予想よりもはるかにうまく機能しているgrail/flexハイブリッドアプリに取り組んでいます。私はGWTを見てきましたが、当時はGWTに関する本があまりなく、Swingのようなプログラミング手法を活用することを強調しているようでした。それらをすべて試してみるというコメントに同意します。彼ら全員が持っているhelloアプリを実行し、変更がどれほど難しいか簡単かを測定します。また、ツール（IDE、Maven、CI ...など）のサポートも、すぐに生産性を高めるという点で大きな要因になる可能性があります。

于 2010-03-18T04:50:58.010 に答える
2

残念ながら、答えは意見が分かれます。最も純粋な形のGWTは目を見張るものではありません。そうは言っても、ExtJsGXTは非常にハンキーなドーリーです。進化するフレームワークで私が直面する主要な問題の1つは、完全に欠陥がないわけではないということです。正しく覚えていれば、GWT 2.0は、新しいレイアウトの一部にCSSスタイルがない状態で出荷されました。過去5日間からExtJs/GXTで問題をトラブルシューティングしようとしています:(、フレームワークは多くのことを難読化します。絶対に堅牢で適切なエラーメッセージを表示するフレームワークを使用します。他の人とは協力していませんが。

于 2010-03-18T04:54:54.277 に答える
2

ここではGrails+ExtJSを使用しています。慣用的なExtJSアプリケーションを作成しようとしているため、Grailsは十分に活用されていませんが、サーバー側の部分に、たとえばJSPの代わりにGrailsを使用することは理にかなっています。

ExtJSが選ばれる理由：GUIのようなWebアプリケーション用の非常に豊富なツールキットだからです。私たちの仕事は古いMotifGUIを置き換えることなので、これがまさに私たちが必要としているものです。

なぜGrails：それは仕事を簡単かつ迅速に終わらせるからです。ExtJS部分との通信には、多くのJSONが必要であり、Grailsでは次のようになります。

import foo.bar.FooBar
class FooBarController {
    def viewFooBars = {
        def list = FooBar.getList(session.userId, params.foo, params.bar)

        def result = [resultset: list] as JSON

        response.setHeader('Content-disposition', 'filename="json"')
        response.contentType = "text/json";
        render result
    }
}

そして、それは必要以上に2、3行です...

于 2010-03-18T13:06:41.460 に答える
2

道場をお勧めします。

Dojo 1.6は、提供する大規模なインフラストラクチャに加えて、ClosureCompilerのAdvancedモードで正常に使用できる最初の（そして唯一の）人気のあるJavaScriptライブラリであり、サイズ、パフォーマンス、難読化のすべての利点があります。 Google独自のクロージャーライブラリ、つまり。

http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t

言い換えれば、Dojoを使用するプログラムは、ライブラリ自体でさえ、100％難読化される可能性があります。

コンパイルされたコードは、プレーンテキストコードとまったく同じ動作をしますが、はるかに小さく（ミニファイアの平均25％）、実行速度がはるかに速く（特にモバイルデバイスで）、リバースエンジニアリングがほとんど不可能です。コードベース全体（ライブラリを含む）が難読化されているため、ビューティファイア。

「縮小」されたコード（YUIコンプレッサー、Uglifyなど）は、美化機能を通過した後、簡単にリバースエンジニアリングできます。

于 2011-03-10T10:32:21.840 に答える
1

ExtJsは、複雑なWebアプリケーションの作成に最適です。APIは、Webアプリで想像できるすべてのものを提供し、しばらくするとコンポーネントを簡単に拡張できます。

それを任意のバックエンド（djangoまたはphpを使用）にプラグインして、いくつかの異なるアプリケーションで任意のコンポーネントを再利用または拡張できます。

あなたはそれに快適に感じるために数ヶ月を必要とします。私見では。

とは言うものの、ウェブサイトのような単純なuiにはlibが少し遅すぎることがあります（その場合はExtCoreを使用できます）。しかし、webappsに関しては、これは問題ではありません。

私はJavaの人ではないので、GWTは私にとってオプションではありませんでした：/

お役に立てれば

于 2010-11-01T15:14:02.047 に答える