WicketをRubyで実装する会コミュのWicketについて語りましょう(About Wicket)

自己紹介スレッドがかなーりずれてきたので
あらためて新しいの立てました。

akrさんのwikiを参考にして、恒例のHello Worldを作成してみました。（ぱくっただけ）
感想は、Swingマニアとしては、似ているとこがあって面白いのですが、クラスファイルが多くなりません？

コメント(14)

最初
全て
最新の40件

[4] mixiユーザー 08月09日 13:31

カルピスパート２さん

僭越ながら、提案なのですが、
今後のこのコミュの方向性とそれを踏まえた上での
線引きなど（マイルストーン含め）決めていきません？
ダメ？

[6] mixiユーザー 08月16日 19:11

こんにちわ。Swingは詳しくないです。Delphiは馴染んでます。VBも少しやりました。RubyのBlockつきメソッドも好きです。

> なぜSwingと同じようにListenerを採用しなかったのだろう？

Listenerクラス自体が増えるから。…というのは冗談ですが(^^;。

JavaのListener(interface)って特定のメソッド名を要求しますから、 1つのListener側オブジェクト(のクラス)に複数のGUI部品からの同種イベントを(しかし別々の振る舞いで)処理してくれと依頼されたら、それはそれで頭痛いことになりますよね。 Listenerの肝のメソッドの中でイベント元の部品がドレだったか？というif文を書く羽目になる。

Delphiのメソッドポインタ方式だと、
同名じゃなくても同型(引数が同じとか)のメソッドを
Listener(みたいなもの)として指定できるので、
Listenしてくれるオブジェクトやクラスを増やさずに済みます。1つのクラスに名前違いのListen担当メソッドを複数作ればいい。

いや、それが正にListenerがやりたいこと(同じオブジェクトにごちゃごちゃ入れるなよ！という教え)なのだと思うのですが、
それってつまり、
「クラスは増加する」
ことを
「嫌うな！」
と言ってるのとイコールですよね(^^;

実際は、クラスが増えることもまた、面倒の1つだというのに、です。
カルピスパート２さんは「クラスは増加する」ことを「懸念」してらっしゃるのだと思います。ですよね？

つまりListener方式って一長一短なのじゃないでしょうか？

個人的には、onHoge方式は、簡便に話を済ませたくてしかもこれで十分な場合は、使うほうが嬉しいだろうと思っています。

ところでこれはRubyだと、Blockつきメソッドがよく使われるケースだと思います。

class Fuga implements hogeListener{
void onHoge(){
やりたい処理
}
}

button.addHogeListener(fuga);

じゃなく

button.onHoge{やりたい処理}

といった感じ。だいぶ短くなるあたりがrubyの嬉しいところです。

実用的には、ボタンの生成とボタンの振る舞いの定義とを「遠くに離して」おくのって、管理的に面倒じゃないかと思っています。
RubyのBlock方式だと正に目の前です。とても嬉しい。
ListenerだとそれをImplementsしてくれたドコのClassにでもイベント処理を置けるので「便利」ですが、その自由度の高さのせいで逆に「あれ？どこに定義したっけ？」ってなことにならないかなーと(^^;

長文すみません。

[8] mixiユーザー 08月17日 11:25

こんにちわ。

私としてはDelphiは
嫌いなとこ＝Pascal(伝統的な意味での)を使ってること
好きなとこ＝それ以外のほぼ全て
でした(^^;
Borlandによる言語拡張やVCLやIDEは素晴らしいんだけど、 Pascalの古さ(OOP時代にそぐわない過剰な順序縛りとか)が足引っ張ってるという印象です。しかも事実上Winべったりなので、JavaとDelphiの美味しい処取りのC#が(MSから)出た時点で、先細りは運命付けられてたかと。惜しいですが。

ところでRubyでは「=」で終わるメソッド名を作ることで、DelphiのProperty(setter側)とソックリなことをやれます。そういうコードを書いてるとDelphiの素晴らしさを懐かしく思い出します。そして同時にRubyの旨さに恐れ入ります(propertyという構文要素を追加せずとも、メソッド命名ルールを少々拡張するだけで、同じ効果を実現してる)。

>すみません。

あ。いえいえ。謝ることでは無いと思いますし。お手をおあげください(^^;

ただ、一長一短あるなかで、「Wicketの中の人は」Listener方式を捨てるという判断をした、とは言えるんだろうと思います。どっちもどっちだけどじゃあどっちにする？と問われてonHoge方式を選んだと。

で、ここからは私の抱く印象なんですが、ListenerよりonHogeのほうが、最近の流行り言葉でいう「設定より規約」的発想に近いと思います。決まりきった書き方を守ることでコードを簡素にするっていうアレ。逆に自分で能動的にListenerを作るほうは「設定」に近い考え方に思えます。

そして今我々はRubyを取り上げてるので、時流に乗る(^^;なら我々も簡素方向に道が拓けてるのかな、と思います。

Rubyだと、Blockとか、特異メソッドとか、アプリのコードを短くするために役立つ道具が色々使えるんで、嬉しいですよね。

ーー

Railsの、どーすればアプリ側のコードの長さが極限まで短くできるか？を追求したライブラリ構成は、ちょっと凄いなと思いますし、見習いたいとも思っています。

ただ一方で、Railsでも採用してるMVC(2)は、必要なファイルの数や長さが増えがちじゃないか？という気がしています。
というか個人的印象ですが、"ゴチャゴチャしてる"って印象を持っています。OOPのメリットが却って薄いというか。

つまりWicket方式だとRailsより更にアプリコードを短く簡素にできるんじゃないか？と妄想してます。ん？もしかして世界最強？(^^;;;

細かい話はともかく、ぶっちゃけ言えば「Wicket方式＝VB/Delphi方式の復権！」と思ってます。夢よ再び(^^;

[10] mixiユーザー 10月05日 14:36

最近なにもしてませんm(__)m

ところで RubyWebDialogs
http://www.erikveen.dds.nl/rubywebdialogs/index.html
http://jp.rubyist.net/magazine/?0001-RubyGUI#l19 (るびまの紹介記事)
って、Wicket路線にも通じるかなという気がしてます。
糞XMLを使ってる点を除けばですが(T_T)

WebアプリというよりはGUIを(ブラウザに)表示させるというスタンドアロンアプリ的発想だそうですが、まあ動作原理はWebアプリですよね。
セッション(マルチユーザ)管理をしてるかどうかは不明ですが。

あと糞XMLを「わびさび方式 http://jp.rubyist.net/magazine/?0012-qwikWeb#l8」あたりに挿げ替えてくれたらいいのになあ。
なんか中ではXMLをパースしたりしてますが、わびさびなら最初から(Rubyインタプリタが)パース済みのTREE状構造物を渡してくれるので、悩み無用になるのになあ。

あ。わびさびTREE構造といえば、http://hpcgi2.nifty.com/guion3/tiki/tiki.cgi?c=v&p=ruby/ArrayUp こんなの作ってみました。
TREEの各要素(LeafまたはArray)のupメソッドを呼ぶと「親」に移動できます。

[11] mixiユーザー 10月05日 18:41

> 戯音さん

私も最近なにもしてませんでした(苦笑;
ご紹介して頂いたサイト参考にさせて頂きます。有難うございました。

[12] mixiユーザー 12月11日 13:28

こんにちわ。またしても横っちょの話ですみません(^^;

詳しい事情は知りませんが多分Wicketの直接的ライバルなんだろうと思う、「Click」Frameworkの、
紹介記事が出てますね。
Click Framework探訪 http://www.ogis-ri.co.jp/otc/hiroba/technical/ClickFramework/clickfw01.html

＃あれ？Clickのコミュは無いみたいですね？

以下、私の雑感です。

>Pageクラス
>Controlクラス

へえ。拙作WebDesktopServerでは、それら両者のクラスは統合してます。
Pageは単に「トップレベルのControl」っていうだけ。

>ページテンプレート

いつも思うんだけど、なんで「コントロールテンプレート」じゃないんだろう？

要するにページを(コントロールのうちで)特別扱いするのって
避けたほうが良いんじゃないの？と思うんだけどなあ。

ページなんて、コントロールの組み合わせをtoStringして得られるHTMLが
結果的にたまたま1つのファイルになることで得られる副次的なもの
だと思うんだけどなあ…

…と疑問に思って「コントロールテンプレート」ググってみたら、
なんとMSのASP.NETがうじゃうじゃヒットしました(^^;;
やばい。もしやライバルはMS？

>public CommentPage() {
>commentTable.addColumn(new Column("id", "ID"));
>commentTable.addColumn(new Column("email", "E-MAIL"));
>commentTable.addColumn(new Column("commentText", "comment"));
>commentBox.add(emf);
>commentBox.add(cmf);
>}

この辺はRubyだと「わびさび方式」がお洒落じゃないかなあ。
もちろんJavaと同様に
コンストラクタでControlを並べる(という命令をくだす)のも出来るけど、
それよりは昨今流行の「宣言的」な並べ方のほうが扱いやすそう。

class CommentPage
　control [
　　[Table, :commentTable,
　　　{:cols=>[
　　　　　col(:id, "ID"),
　　　　　col(:email, "E-MAIL"),
　　　　],
　　　},
　　],
　　[Box, :commentBox, [
　　　　emf,
　　　　cmf,
　　　],
　　],
　]
end

[14] mixiユーザー 12月12日 01:22

やっぱりStrutsのような画面遷移指向
(アクションが画面と画面の「間」に有る)
ってのは、
OOP(やMVC)というよりは、
むしろPipelineアーキテクチャ
(UNIXのコマンドラインなんかで有名なアレ)
に近いんだと思います。
少なくともあれをMVCと呼ぶのはお門違いだし※、
個人的には全く好きになれません。

※
あれをMVCと呼ぶのは、
JavaScriptがJavaにあやかって(技術的共通点が乏しいのに)命名されたのと
似たようなもんでしょうかね。

ふれーふれー画面指向！なのですよ。

イベント駆動方式のWeb(に限らないが)アプリフレームワークは、
アクションは画面の「間」ではなく
画面の「下」にありますよね。
うまくいえないんだけど、なんというか、画面の「配下」に。
処理が画面(の中の各々のボタンとか)にぶら下がってる。

遷移のついでにアクションをするんじゃなく、
アクションのついでに(必要な場合ならば)遷移する、
という程度のが、ちょうどいいんだと思っています。

>FrameWork群雄割拠

少なくとも画面遷移指向のが勝ち残っては、ほしくないですねえ。
JSFも最初は期待したのですが、気づいたら「あっち側」の住人になっちゃってたし(T_T)

ログインすると、みんなのコメントがもっと見れるよ