アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
そうなの？？？ (スコア:0)
むしろAjax的には後発じゃ？もともとはFlashを生成するんだよね。
面白い製品だとは思うけど、も少しカジュアルに使えないとCurlの二の舞になりそうな気も。
Re:そうなの？？？ (スコア:2, 興味深い)
ライブラリとして作るか、JavaならばMBeanにしちゃえば、既存のJ2EEなシステムとかと統合できるのに…
# おまえがヤレと言われると、アレだけど
Re:そうなの？？？ (スコア:3, 興味深い)
「なぜGUIライブラリがフレームワークか」という問いに(技術的な)一般論で答えるならば、
Callbackをしたい(させたい)から
ですよね。
こっちから呼ぶだけなら描画しかできない。それじゃ静的な絵でしかない。
そうでなく、画面上のどっかをClick/Drag「され」たときに
呼「ばれる」コードをライブラリユーザに書かせるっていう
「制御の逆転」(Inversion Of Control)のお膳立てをしたいからです。
つまり受身プログラム。伝統的に言えばイベント駆動。
ただ、こういう話を書かれる人ならばトウにご存知とは思いますが、
わざわざフレームワークと言わずとも、
オブジェクト指向でライブラリを作れば自ずと
継承(TemplateMethodPattern)等でCallbackの仕組みを使うことになるので、
ご懸念のように「わざわざフレームワークでなくていいのでは？」という疑問は
十分有り得ると思います。
(言い換えればオブジェクト指向であるということは元々フレームワークだ、ともいえますが、それはさておき)
ここから先は私もよく判りません(^^;
「フレームワークっぽさ」を可能な限り廃しまくって、
それで尚GUIライブラリを構築することが出来るのかどうかは、
ちょっと答えが見えていません。
また、「可能な限り」…つまり「どこまで」やれるのかという程度問題なのかも知れません。
実装しろとは言いませんが、
どういう方針でライブラリを作ればそういうものが出来そうだと踏んでらっしゃるのかは、
ちょっと語っていただけると嬉しいです。
＃だって、そうでもしないと、「ナードのためのサイト」だったはずのスラドで、いつまでたっても技術的談義が出来ないんだもん。そりゃ人気も出ないわな。
MBeanは疎いので、なんともコメントできません。
ただ、MBeanとかが有る世界自体が既にフレームワークなんじゃないの？とは思うのですが。
もしかして「フレームワークを作るな」じゃなく
「新しくフレームワークを作るな」という主張なのですか？
Re:そうなの？？？ (スコア:1, すばらしい洞察)
Lazloはよく触った事が無いので、それに限った話でなくフレームワーク待望論として。
ユーザー側の事情として、最初から作り直しになっても全部入りのほうが、
捺印ナビリティ [google.co.jp]が高いからでは？既存のアプリに組み込む場合、ピンポイント
で置き換える必要性の説明が結構大変だったりして、まずは新規案件でドカッと
実績を作ってプレゼンしてしまうほうが橋頭堡を築きやすい気がします。
新規案件のほうが予算出しやすいし、チャレンジングな提案に寛容な場合が多い。
また、フレームワークにユーザーが期待するものって、手順や仕様の平均化で
あったりして、組み合わせを自由にするより全部入りで制約をもってるほうが、
安心ということがあるのではないでしょうか。
日記の追記 [srad.jp]にここでレスさせていただくと、構成時に自由にしたい、
という目的もあるでしょうが、J2EEを利用するプロジェクトは特に拡張の自由度より、
規約制約を固めて進んだら後から変更を変える融通を受け付けて貰えない気がします。
ちょっと取り入れてみたい、って半端で軟派な提案しても、将来自分がいないと恨まれるし。
AJAXという曖昧な定義（特定の方式組み合わせを指していないなど）をベースにする技術を、
個々の技術者の知見に頼って実装してもらっては困るというのが、人の出入りが激しい案件には必要で、
逆に言うと今までは双方向性を求めず、枯れた技術が支持されていたような、そうした案件においても
AJAXのもたらした革命を無視できなくなっているという事でしょう。