Smart GWTできまりだろJK と前から思っていたのだが、今でも変わらないようだ。 きしださんのエントリではExt GWTを見せていたようだが、Smart GWTのほうがはるかに利点が多いと思う。 まずライセンスがLGPLであること。EXT GWTはGPL or商用ライセンス。MySQLとにたようなものですな。価格は以下を参照。 http://extjs.co.jp/store/gxt/ 続いて軽さ。Firefoxみたいに早い場合は気にならないけど、IE6やIE7あたりだと結構違う。IEを無視してよいというところはおそらく少ないだろうからこれは結構でかい。(コンポーネントが増えるとEXT GWTのほうが重くなりやすいです。) SmartGWTを知ったのはこれかな。 http://www.infoq.com/jp/news/2008/12/smartgwt Smart GWTのショーケー
GWTのウィジェットライブラリであるExt GWTとSmart GWTの比較。 id:shinさんとは意見が違うので、書いておきます。 http://d.hatena.ne.jp/shin/20091127/p2 Smart GWT Ext GWT ひとつ、最初にお断り。Ext GWTではプログラム組んだことがあるけど、Smart GWTはAPIやサンプルコードを追っただけなのと、Ext GWTはもうライセンス料払ってるので、おそらくExt GWTよりの評価になっています。 まず、IE6の対応について。IE6の場合、JavaScriptが重すぎて処理が書けないので、ブラウザでフルアプリケーションは組まないほうがいいと思います。 つまり、Ext GWTもSmart GWTもIE6にとっては重いので、やめたほうがいい。普通に苦情が出るレベル。IE6をサポート範囲にしないといけない場合は、普通の
Java仕事で各種フレームワークを比較検討したので、比較用に作った参考資料を公開します。ちなみに現在私は、ドワンゴさんの社内システム開発をお手伝いしてまして、その一環で調べたものです。会社資料じゃなく、私の資料ということでブログで公開してよい、むしろしとけ、とのことなので公開しときます。 今回の案件向けにアプリケーションを画面層コンテナ層データアクセス層に分けて、それぞれフレームワークを選ぶのが目的です。コンテナ層はDIコンテナのうちいずれか、データアクセス層はO/Rマッパーを選ぶことになります。 太枠の範囲が選定対象です。よく本に出てくる杓子定規な階層図とは変えてあります。 次のものを比較検討しました。画面層SAStrutsApache Wicket(ほかにもTeedaとかClick Frameworkとかももともとは候補にあったが、調査が追いつかないので二つに絞った)コンテナSeasa
Railsが成功し、EJB3が失敗したわけは、イノベーションへの解にでてくる「独自仕様の製品アーキテクチャ」と「モジュール方式のオープンな業界標準」の考え方で、うまく説明できるように思えます。 ただし、この手の話は、理論にあうように現実を説明しているところがあるので、あくまでも、1つの可能性として聞いてください。 ここでの重要な考え方は、「顧客のニーズ」と「製品の性能」の力関係です。 「顧客のニーズ」が「製品の性能」を超えている場合は、顧客は、製品の性能向上に価値を認め、お金を払います。このときに企業として、成功しやすいソリューションは、「最適化された独自アーキテクチャ」で望むことです。性能を向上させるためには、独自アーキテクチャのほうが、いろいろ工夫ができるためです。 「製品の性能」が「顧客のニーズ」を超えている場合は、顧客は、製品の性能向上に価値をあまり認めません。既に、製品の性能に満
Java, Wicket このブログをいままで読んでいる方なら、私がApache Wicketの大ファンだということはご存知でしょう。ついに1.3としてApacheプロジェクト入りしてから最初のリリースを果たしたWicketフレームワークは、日本ではまだそれほど普及していませんが、今年は米国で「Wicket in Action」が出版される予定があるなど、かなり注目されているフレームワークです。 私はそんな控えめな表現では表せない魅力をWicketに感じています。Wicketは、Javaのいままでのフレームワーク開発の積み重ねがもたらした「ウェブ・アプリケーションの革命」です。Echo2のようにHTMLを廃してJavaだけでプログラムを組むのでなく、JSFのように新しいテンプレートを作るのでもない。HTMLとJavaを結合して、HTMLをJavaで、Javaらしいコードで制御するという方向
_ [Java][Seasar] Cubby 1.0.0-RC1 リリース Cubby 1.0.0-RC1がリリースされました。詳細はid:agtさんのCubby 1.0.0-RC1 リリース案内をどうぞ。今回のバージョンから@Urlアノテーションが@Pathと@Acceptに変更・分割されたので、既に使っていた方は書き換える必要があります。@AcceptはPOSTやGETなどのリクエストメソッドを限定する新しい仕様なので、今までと同じPOSTもGETも区別しない挙動で良ければ、@Urlを@Pathに置換でサクっと書き換えるだけでOK。 _ [Java][Seasar] Cubbyの良いところ 先日Cubbyで作った2個目の簡単なアプリを予定通り動かし始めました。今のとこ大きなトラブルもないようです。というわけで、Cubbyの良いところを書きたいと思います。ちなみにほとんど同じことがSAS
The Apache Incubator CXF Teamは5日(米国時間)、Apache CXFの最新版となる「Apache CXF 2.0」を公開した。Apache CXFは、Javaで開発されているサービス開発用フレームワーク。JAX-WSのようなフロントエンドプログラミングAPIを活用してサービスの開発を支援する。同フレームワークを活用するとSOAP、XML/HTTP、RESTful HTTP、CORBAなどさまざまなプロトコルが扱えるほか、HTTP、JMS、JBIなどのトランスポートを経由して動作できる。 Apache CXFでは主に次の点に注力して開発が実施されている。 Webサービス標準のサポート さまざまなフロントエンドプログラミングモデルのサポート バイナリサポートおよびレガシープロトコルサポート 簡単に扱えるフレームワークであること Apache CXFではSOAP、B
もう大概聞き飽きているとは思う。ただ、状況はまだまだ固まっていない。 What framework will be the next Struts? (Rick Hightower 『Mastering Rasin』や『Java Tools for Extreme Programming』の著者として有名なRick HightowerさんがIndeed.comで出力した過去9ヶ月の仕事ポスティング量(アメリカ)のグラフを表示している。以下がそのグラフ。 SpringMVCの伸びが好転し、Railsの伸びが鈍化している。Tapestry4.1はDOJOサポートもあったがさほど伸びていない。Tapestryファンとしてはちょっと残念。意外だったのは、Struts2(と言いつつも中身はWebWork2)の開発が少なく、また伸びもあまり見られないこと。確かにStruts2関連の情報は少ないが、それ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く