サーバサイドでのGroovy
Groovyでサーバー側に対応する - GroovletsとGSPを使った即時対応のサーバー側プログラミング
キタ─ｗｗヘ√レｖｖ〜(゜∀゜)─ｗｗヘ√レｖｖ〜─ !!
やはりGroovyはこれから来ますよっ！
まだちゃんと読んでいませんが、JavaのServletやJSPの代わりにGroovyが使えるようです。それだけで、かなり(*´д｀*)ハァハァでつ。
もし、Groovlet*1を書き換えた場合に、動的にその変更が反映されるのであれば、開発効率はかなり上がるのではないかとおもいます。(ただし、warファイルを作ってコンテナに配置するのではなく、開発時に編集しているファイルのあるディレクトリをサーブレットのコンテキストとして設定するとかの必要があるとは思いますが。)
今日のうちにきちんと読んでみたいと思います。Groovyタン(*´д｀*)ハァハァハァアハァ
オブジェクトやクラスは呼び出すものじゃない
http://blog.netbeans.jp/roller/page/kishida/20050423
激しく同意。
最近、他人のJavadocコメントをチェックする機会があったのですが、結構「〜クラスを呼び出し・・・」とかあったりして、突っ込みたくなります。インスタンスメソッドだったりしても、「〜クラスを呼び出し・・・」とか書いてたり。
自分でクラスやオブジェクト、インスタンスといった言葉の意味をきちんと把握して気をつけて使っていたら、このような文章にはならないとおもうのですが・・・
メモ代わりに書きなぐっているような文章ならば特に気にはしないのですが、お客様(しかも開発者)の目に触れる文章で、そのようないい加減さはちょっとモウダメポ..._〆(゜▽゜*)なわけでして。*1
*1:とか書いている自分も気をつけないと結構ひどいです。
Easy Wizard
http://d.hatena.ne.jp/zwfk/20050426/1114449906
http://www.superinterface.com/easywizard.htm
ちょっと変わったWebアプリ用ウィザード*1作成フレームワークです。
Webアプリを作るためのウィザードではなく、ウェブアプリ上でウィザードを作るためのフレームワークということです。
ウェブアプリ上のある一部分に対して使用するといった使い方なら結構有用だと思います。
今までは、自分で細かく状態を管理して画面遷移を実装する必要があったのですが、その手間から解放されるとおもうので。*2
たとえば「ユーザ情報入力」画面や、「ショッピングカート精算」画面とか。
使いまくればほとんどの入力系画面の一連の流れはこれで作れるのかも知れません。ウェブアプリ本体では、全体のフローを定義・実装して、細かい部分はEasy Wizardでとか。*3。
