- 1 名前：デフォルトの名無しさん mailto:sage [2007/01/23(火) 10:59:45 ]
- 前スレ
ttp://pc10.2ch.net/test/read.cgi/tech/1077465099/
公式
ttp://www.springframework.org/
- 149 名前：デフォルトの名無しさん mailto:sage [2007/02/09(金) 16:53:54 ]
- ごめん。今更Strutsなんて使いたくないんだ。
と、>>147でない俺が答えてみる。
- 150 名前：デフォルトの名無しさん mailto:sage [2007/02/09(金) 17:07:07 ]
- では、Web framework 何使ってるの？
- 151 名前：デフォルトの名無しさん mailto:sage [2007/02/09(金) 17:13:03 ]
- んー、Strutsは要件次第ではまだいけると思うんだ。
なによりも成熟してるし実績が無数にある。
JSF・リッチ・テンプレ系は強力だし、
いつでも使えるといいんだけど人的リソースの確保がなかなか…
- 152 名前：デフォルトの名無しさん mailto:sage [2007/02/09(金) 17:15:29 ]
- >>151
同意
- 153 名前：デフォルトの名無しさん mailto:sage [2007/02/09(金) 17:20:00 ]
- >>149だけど、Wicket使ってるよ。
設定ファイルを書かなくていいからもう他のは使えない体だ・・・
でも、結局Spring使ってるからXMLは書くんだけどなｗ
- 154 名前：デフォルトの名無しさん mailto:sage [2007/02/09(金) 18:25:21 ]
- 最近よく耳にするWicketかあ。
プロジェクトの規模は何人くらい？
数名とか小規模なんだよね？
- 155 名前：デフォルトの名無しさん mailto:sage [2007/02/09(金) 21:17:52 ]
- Viewは使いどころにもよると思うが、今はStrutsだろな。
JSFは開発する側はラクだが、使う側からしたら微妙に思う。
Wicketはまだ開発者集めれる段階ではない。
>「フリー（オープンソース）のソフトなんか信用ならねぇ」
こういうの言われるといつも思うんだが、自社製ソフトも信用ならねぇ。バグだらけ。
とつくづく思う。
新規に作ったほうが工数がかかり、多くのバグを仕込むことになることにやつらは気付かないのか？
- 156 名前：デフォルトの名無しさん mailto:sage [2007/02/09(金) 22:49:45 ]
- 作るやつと作らせるやつの感覚が違うのが問題
自分が作るつもりで考えないと生産性なんて
得られないおー
- 157 名前：デフォルトの名無しさん mailto:sage [2007/02/09(金) 23:55:57 ]
- バグの無いプロダクトなんて無いからな。
管理職の考えてるのは「落とし前のつけ方」なんだよね。
フリーでいいソフトありますー採用しましたー失敗しましたー
ってなったときに部下に責任なすりつけて逃げていいんなら採用できるけど。
- 158 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 00:25:40 ]
- そういっていまだにＣ言語やってそう
- 159 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 07:32:34 ]
- >>158
Ｃ言語って何？
おじさん世代？
- 160 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 11:14:20 ]
- 知ったかぶったガキンチョかｗ
- 161 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 11:39:34 ]
- 会社じゃポジションがないおっさんかｗｗｗ
- 162 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 15:39:26 ]
- いまさらながら>>125について解説しておくと、
[UnitTestの件]
UnitTestするにはPOJOで実装する必要がある。
↓
DIなしでPOJOをアセンブルするにはファクトリが必要
↓
ファクトリなんか書くはずない。めんどくさすぎ。
↓
newしまくりで実装
↓
最下層のクラスがコンテナとくっつく
↓
テスト不能
[APサーバの件]
WebLogicのトランザクションを使用
↓
WebLogicはネストトランザクションを未サポート
↓
「WebLogic ネストトランザクション」で検索
↓
dev2dev内のページがヒット
↓
dev2dev「Springのトランザクションマネージャで出来るよ。」
- 163 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 15:57:58 ]
- >>162
すれが活発なのはいいけど、ばかがふえた?
UnitTestするには多くの場合、POJOが望ましいが
POJOである必要はない。
何らかの手段で依存オブジェクトを交換できるように
なっていないPOJOだとテストはやりづらい。
ネストしたトランザクションなんかほとんど使わないよ。
必要だと思っても処理を見直せば何とかなる。
- 164 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 16:03:51 ]
- >>162
んなことわかってるけど、上司にどう言い訳するかってはなし
- 165 名前：164 mailto:sage [2007/02/10(土) 16:04:54 ]
- ごめん
>>162じゃなくて
>>163
- 166 名前：デフォルトの名無しさん [2007/02/10(土) 17:01:19 ]
- 素朴に疑問なんだけど、Spring使って開発楽になった人っている？
キレイになったとか、テスト用意だったとかじゃなく、あくまで結果楽になった人。
- 167 名前：デフォルトの名無しさん [2007/02/10(土) 17:01:50 ]
- ていしえ：テスト容易
- 168 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 17:18:54 ]
- まだまだチーム全体で経験不足なので、楽になったとは言えない。ただ、可読性とかはあがったと思う。
トレースログとか、トランザクション周りを排除できるだけでも使う価値はあるとおもう。
トランザクションの設定はわかるやつが統率して更新したほうがいいよ。
新しいこととか流行の物を使わせるとモチベーションが上がるやつもいる。
そういうやつはそこそこ使えるからいいけど、なんで新しいものおぼえなｋｙ（ｒｙってやつには不評だね。
前者 -> メリットとか関係なく新しいものがつかればいい
後者 -> メリットとか関係なく勉強するのがやだ
俺も年取ると後者になるんだろうなぁ。今はちょうど中間にいるってかんじ。
Ajax系のライブラリも乱立するし、SpringMVCだとか余計なのもでてくるし、次から次へと新しいのがでてくることに飽きたというかうんざりというか。
- 169 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 17:33:04 ]
- .NETにようこそ
- 170 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 18:02:24 ]
- >>168
Seasarにいらっしゃ〜い（三枝風）
- 171 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 18:06:50 ]
- >>168 に近い感覚。
- 172 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 18:07:22 ]
-
工エェェェ（´д｀）ェェェエ工
- 173 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 19:05:52 ]
- 昨年末に買ったSpring2.0入門やっと読破したｗ
いいねこの本
- 174 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 19:09:12 ]
- >>173
だんな乙
なんて言わないですよ
だってここはSeasarスレではないのですからｗ
- 175 名前：166 [2007/02/10(土) 19:25:44 ]
- >>168
なるほどねぇ。
いやぁ、私もSpring使った開発に足つっこんじゃってて。
正直、使う前に予測してた弊害にモロにやられてるから。
ノウハウが足りないってのもあるけろ。
改めて思うのは、DI自体にそこまで価値あるのかしらっていう。
>>トレースログとか、トランザクション周りを排除できるだけでも使う価値はあるとおもう。
激しく同意だけど、これってAOP的要素なんだよね。
オブジェクトの疎結合によるメリットはまだイマイチ感じれないなぁ。
- 176 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:21:51 ]
- ただ導入すればメリットをえられると思っている単細胞には、ﾅﾆを使ってもメリットは得られないだろうねぇ
そういうヤツは何も考えずにゴリゴリ書いてガッツリ結合したプログラムを、またゴリゴリメンテナンスするのが
日常だから、考えてプログラム作ること自体がデメリットになっちゃうんだよね
そういう奴らが主導権を握ったプロジェクトだと、こっちまで巻き添えくうから困る
- 177 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:23:19 ]
- >>175
使う前に予測してた弊害って何？
- 178 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:38:13 ]
- 疎結合そのものにメリット感じられないなら
DI使ったプロジェクトには来ないで欲しいよ・・
- 179 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:39:20 ]
- って言うか、オブジェクト指向言語使った開発全般に（ｒｙ
- 180 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:41:44 ]
- >>175
まずは依存関係逆転の原則でググれ。
- 181 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:43:54 ]
- >>175
>> 激しく同意だけど、これってAOP的要素なんだよね。
そうなんだよね。AOPを使ってトランザクション制御を書かなくていいんだ！ってのは理解してもらえるんだよ。
try,catch,finally close()とかはみんな煩わしいと思ってるし。
問題はDIの部分なんだよね。
setterインジェクションでDaoとか渡さなくても自分でnewすればいいじゃんてなる。
やれInterface書くのめんどくさくないの？とかsetter書くのがめんどいだのいうわけよ。
Daoなんか1個実装すれば終わりだし、ORMが途中で変わるわけないだろとか。
うちの人間は極端にリソースが増えるのを嫌がるからなぁｗ わからなくもないんだけどね。
- 182 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:45:07 ]
- Interface書くのがめんどくさいとかいうヤツは
コボルでもやってりゃいいんだよ
- 183 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:46:26 ]
- >>181
そういう奴らの方がよっぽどめんどくさい事を一生懸命やっているっていう事実を
当人達が気が付いていないのが笑える
- 184 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:46:53 ]
- >>181
自分でnewして良いかどうか、
JUnitでテストケースかいてみりゃ一発でわかるだろ。
- 185 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 20:53:15 ]
- PGレベルのやつはspring意識しなくて良いから「勉強ダルい」なんてことはないと思われ。
上でもあるが、トランザクションやログなど、アプリケーションの動作をプログラムから排除することで、
オブジェクト指向設計したメソッド呼び出しのみに注力することができるので見通しが良くなる。
- 186 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 21:07:56 ]
- 蜜結合大好きならスクリプト言語の世界へどうぞ。
- 187 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 21:44:14 ]
- 宣言的トランザクションを利用する場合も
TransactionManager, DataSourceなどをBean定義ファイルで設定してるよね？
あれってDIだよね？ｗ
これはkiddingだけど、
DIの価値がよくわからなければnewすることからはじめてもいいのでは？
それで問題がなければＯＫだし、その過程でDIの良さを理解できるかもしれないし。
一気にモジュールを作成してUnit Testをせずに
結合して単体テストするという文化ではnewでいけるのかも？
- 188 名前：デフォルトの名無しさん [2007/02/10(土) 22:21:29 ]
- 飲み過ぎだろ・・・常識的に考えてｗｗｗ
- 189 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 22:22:41 ]
- 誤爆しましたｗ
- 190 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 23:37:41 ]
- あなたの常識って何ですか？東国原
- 191 名前：デフォルトの名無しさん mailto:sage [2007/02/10(土) 23:53:40 ]
- ＞DIの価値がよくわからなければnewすることからはじめてもいいのでは？
＞それで問題がなければＯＫだし、その過程でDIの良さを理解できるかもしれないし。
単に、問題の存在に気づかないだけだとおもう。
- 192 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 00:07:00 ]
- かもなｗ
- 193 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 00:08:26 ]
- >>191
問題って何？
- 194 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 00:20:52 ]
- 理解力不足と、そう思われるのがイヤで
難癖付けるヤツ
- 195 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 00:22:42 ]
- 自分自身のこと？ｗ
- 196 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 00:26:03 ]
- あと、空気読めないガキ
- 197 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 00:26:37 ]
- なんか現状に不満みたいだねｗ
- 198 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 01:54:09 ]
- >>191-197
これがSpringを導入するかしないかで繰り広げられる会話か。
- 199 名前：166 [2007/02/11(日) 02:53:16 ]
- うあ。大反響だ。
この中で実際開発してる人っているんですよね。
理想論は理解できるけど、どれだけ『体現』してるのかな。
それも個人ではなくプロジェクトとしてね。
ISID内じゃ前からSeasar2不評だよ。
タ ブ ー だ け ど 。
- 200 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 03:03:48 ]
- >>199
どうでもいいけど、>>175で書いてた、使う前に予測してた弊害って何よ？ｗｗｗ
- 201 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 03:04:13 ]
- 疎結合否定した時点で、真性かネタの二択だよ俺的には。
- 202 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 03:05:27 ]
- 今時DIすらわからんJava開発者は、さっさとRubyあたりに移った方が身のためだと思う
多分Rubyもわからなくて廃業するだろうけどな
- 203 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 04:05:38 ]
- 実際、楽になったといえるような香具師はいないだろうねぇ
Strutsがそうであるように、結局使いこなせなくて大変な思いだけ
が記憶に残ってしまうんだよね
とSpring使ったことないオレがイって見る
- 204 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 04:30:32 ]
- だからさっさとスクリプト言語でも何でも、簡単な方にいけばいいのに
DI以前のクソソースしか書けないJava開発者が、現場では一番使えない
- 205 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 05:27:13 ]
- ｸﾝｸﾝ
ﾑﾑｯ！！
ｺ・・・ｺﾚﾊ！！！
- 206 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 08:49:34 ]
- >>203
とことん楽になったよ。
あとStrutsと比較したらただのアホだから、
人前では決して口にしないように。
DIは(AOPも)パラダイムなんだから。
構造化言語、オブジェクト指向、とかと同列。
進化の方向は「関心ごとを極小にして実装に集中する」で一致してる。
- 207 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 10:41:51 ]
- >>203
Javaも使いこなせてないみたいだな
- 208 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 10:44:20 ]
- >>204
人の上に立てないやつ
- 209 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 10:47:07 ]
- >>199
>ISID内じゃ前からSeasar2不評だよ。
これほんと？(ぁゃιぃ)
不評な理由はなに？
- 210 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 11:01:34 ]
- なんかさ、
ジャヴァ・スプリング・フレームワーク と
ネギ・スプリング・フィールド って
なんかにてね？
- 211 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 11:03:50 ]
- ネギ・スプリング・フィールドはおまえにそっくりだな
- 212 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 11:59:28 ]
- なんか暖冬のせいか、馬鹿がたくさん沸いてでてきてるな
- 213 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 12:00:39 ]
- >>206-207
そういう意味で比較したんじゃないからｗ
日本語も読めないようなヤツだと大して使いこなせてもいないんだろう
- 214 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 12:16:30 ]
- 必死だなｗｗｗ
- 215 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 12:43:38 ]
- ネタだと思いたい。
- 216 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 12:44:51 ]
- >>212
そりゃ、春のフレームワークだからなｗ。 Spring = 春
- 217 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 12:53:49 ]
- バネもってこい！
- 218 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 12:59:28 ]
- 温泉のフレームワークじゃないの？
- 219 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 13:28:49 ]
- スプリングフィールドとかって名前の外人さんいそうじゃねｗｗｗ
- 220 名前：デフォルトの名無しさん [2007/02/11(日) 13:34:40 ]
- DIの考え方は肯定するがDIの存在は否定するよ。
DI使いこなせるやつは密結合でもちゃっちゃと作れる。
DI理解できないやつは密結合の方が早かったりする。
現実問題として多数の人間が後者なんだよ。
この状況でDIコンテナ導入するのは最適かね。
私が言っていた弊害てそういうこと。
ムキになって噛みついてきてる方々は、普段からあまりDIの良さをわかってもらえず、もどかしい思いをしているのかな。
残念ながら多くのプログラマは君達よりずっと馬鹿。
有識者やセンスある人の内輪で盛り上がり、気付いたらJavaの市場規模は縮小してました なんて平気でおきそうで。
『誰にでも』簡単に、より速く これが理想でしょ。
まあ上位開発者がフレームワークでDIを完全に隠蔽できればどーにかなるんらけろ
- 221 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 13:42:17 ]
- >>220
作業の分担の仕方を変えれば、あっさりうまくいくよ。
旧来式：
・うまい奴が難しい業務
・下手な奴が簡単な業務
DI導入後：
・うまい奴が全業務のインタフェースを切る
・下手な奴はインタフェースを実装する
- 222 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 13:55:20 ]
- >>221
そのうまい奴がいないでDI導入するプロジェクトが存在する訳だが・・・
- 223 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 13:58:16 ]
- >>222
それは流石に無謀だろｗ
- 224 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:08:48 ]
- うまい奴がいないプロジェクトはDI導入しようがしまいがこけるでしょｗ
- 225 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:10:14 ]
- 自分はわかっていると思っているヤツがいるプロジェクトが一番危ういｗ
- 226 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:11:41 ]
- DIxAOPの宣言的トランザクションや他フレームワークとの連携機能は使いたいが、
DIのメリットが享受できない、理解できない場合は蜜結合すりゃいいんだよ。
- 227 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:12:16 ]
- 220は導入主導したやつにうまい奴だと期待されたんだな。
お前は何も悪くない。そいつの目が節穴だっただけだ。
＞上位開発者がフレームワークでDIを完全に隠蔽できればどーにかなるんらけろ
こんなのは当たり前にやってることなんだよ、普通なら。
- 228 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:15:42 ]
- >>225
他の奴がわからないと、調べろよとか、
そんな馬鹿な奴らと仕事したくないとか、
俺が５人いたらなとか言う奴がアーキテクチャーを
仕切っていると確かにやばいなｗ
そういう奴は自己中でプロジェクトの成功だとかコストといった観点が抜けてる。
- 229 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:21:33 ]
- >>222だが、
DI導入を推進してすんごいインターフェースきりまくった奴が逃げ出した
残骸見る限り使い方もわかってない様子。
- 230 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:22:15 ]
- >>228
＞他の奴がわからないと、調べろよとか、
＞そんな馬鹿な奴らと仕事したくないとか、
むしろDIコンテナは、雑魚に何らの調査力を期待しないで済むように
デザインされていると感じるが。
- 231 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:24:00 ]
- >>229
何がいいたいかわかんね
- 232 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:24:47 ]
- DIコンテナといったコンテキストの話じゃない
- 233 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:27:27 ]
- >>229
それはDIうんぬんの問題というよりも
そいつが技術的に仕切れる奴じゃなかったという話では？
- 234 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:33:18 ]
- そういう話
- 235 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:47:11 ]
- よし、今からDIとやらをやるぞ。
ところでJavaもプログラム言語も
ほぼ素人の新人なのだが、
勉強すべき用語をリストアップしてくれ！
- 236 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:51:10 ]
- >>235
1. 単一責任の原則（SRP：Single Responsibility Principle） クラスを変更する理由は1つ以上存在してはならない
2. オープン・クローズドの原則（OCP：Open-Closed Principle） ソフトウェアの構成要素（クラス、モジュール、関数など）は拡張に対して開いていなければならず（オープン：Open）、修正に対しては閉じていなければならない（クローズド：Closed）
3. リスコフの置換原則（LSP：Liskov Substituion Principle） 派生型はその基本型と置換可能でなければならない
4. 依存関係逆転の原則（DIP：Dependency Inversion Principle） a. 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきであるb. 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである
5. インターフェイス分離の原則（ISP：Interface Segregation Principle） クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない
- 237 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:53:55 ]
- >>235
仕事ならマジ勘弁してくれ
- 238 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:54:07 ]
- SRP、OCP、LSP、DIP、ISP だな？
他に知っておく技術は無いか？
俺は素人だからな。当然基礎的なものから全部だ
- 239 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:54:46 ]
- 「人」についての理解が重要です。
- 240 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:55:42 ]
- >>238
それらを習得する過程で必要なものは全て手に入る。心配するな。
- 241 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 14:56:38 ]
- >>240
その必要なものをすべてリストアップしてくれ！
- 242 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:05:25 ]
- >必要なもの
他の業界への転職
- 243 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:06:15 ]
- 明らかにスレ違いだと分って聞きます。すみません。
Spring Frameworkのような仕組みで、
デスクトップアプリを作ろうと思えば
なにを使えばいいのでしょう？
最近のフレームワークは
WebアプリでHTMLやHTMLっぽいテンプレートを
使ってUIを実装する話しばかりで困ります。
- 244 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:08:23 ]
- Spring Frameworkのような仕組み とは？
- 245 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:10:04 ]
- >>243
日本語でおｋ
- 246 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:14:43 ]
- >>244
えぇ、ですからいわゆるウインドウで作りたいのです。
Windows Formsとか、GTKとかQTとか。
- 247 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:17:15 ]
- お前はSpringをなんだと思ってるんだ？
- 248 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:19:34 ]
- もう一度聞く
Spring Frameworkのような仕組み とは？
- 249 名前：デフォルトの名無しさん mailto:sage [2007/02/11(日) 15:21:23 ]
- >>243
電子レンジのような仕組みで、
デスクトップアプリを作ろうと思えば
なにを使えばいいのでしょう？
と質問されたら貴方はどう答えますか？
|
 |
