国産オープンソースDI ..
39:デフォルトの名無しさん
04/08/10 08:47
漏れはS2で作って納品しましたが何か？
一人有限なので今年はこれで十分かと思ってますが何か？
40:デフォルトの名無しさん
04/08/10 09:00
>>29
> DIファイルに何が書けるかももちろんどこにも載ってない。
components.dtd見れ
41:デフォルトの名無しさん
04/08/10 09:02
>>29
> S2Hibernateのドキュメントが特徴的なんだけど、コメントもないソース列挙しておいて
> 「簡単に利用できるということが分かっていただけたと思います。」
> と書いてしまう感覚の持ち主。
まずはhibernate使えるようになろうな。話はそれからだ。こっちいけ
ｽﾚﾘﾝｸ(tech板)l50
42:デフォルトの名無しさん
04/08/10 09:04
>>29
> ひがさんのお友達以外には、使う価値はありません。
なんだひがさんに嫌われてるやつの粘着か。つまらん。
43:デフォルトの名無しさん
04/08/10 09:07
>>39
> 一人有限なので今年はこれで十分かと思ってますが何か？
そーだよな。自分ひとりでやるなら、自分だけわかってりゃいいからな。
44:デフォルトの名無しさん
04/08/10 09:13
そうだな。頭悪い奴とこれ以上一緒に仕事できねーって思って
独立したから一人で出来る程度しかやらないよ。
ちゃんと保守契約も結んでるから問題ナッシング。
さくっと納品できたので金額を考えるとおいしい仕事だったよ。
S2はありがたいよ。
45:デフォルトの名無しさん
04/08/10 09:15
そんなつまらんことでスレ立てたのか。
まったくスタンドプレーの好きな迷惑な奴だな。
46:デフォルトの名無しさん
04/08/10 10:00
>>43
> そーだよな。自分ひとりでやるなら、自分だけわかってりゃいいからな。
漏れのとこは、無理だな。
旗振ってもついてこねーだろうし、上司もいい顔しねーよな。
47:デフォルトの名無しさん
04/08/10 13:10
なんだ、単なる宣伝スレか。
48:デフォルトの名無しさん
04/08/10 13:31
ならもっと宣伝してよ。
49:デフォルトの名無しさん
04/08/10 14:22
S2の作者の会社(電通国際情報サービス)で、有償サポートの検討開始だってさ。
価格はプロジェクト単位の年間サポートで50万。
URLﾘﾝｸ(d.hatena.ne.jp)
日本発のオープンソースビジネスかな？めでたし、めでたし。
これまでS2を盛り上げたみんな、お疲れ様でした。
50:デフォルトの名無しさん
04/08/10 15:53
>>49
よかったよね。サポートを欲しがる客でも
安心して提案できるようになるね。
これでもっとS2を使っていきやすくなるよ
51:デフォルトの名無しさん
04/08/10 17:12
SRAを忘れるなよ＞日本発のオープンソースビジネスかな？
52:デフォルトの名無しさん
04/08/10 19:12
>>51
> SRAを忘れるなよ＞日本発のオープンソースビジネスかな？
作者が日本人ということでは、多分初めてじゃないかな。
Rubyはどうなんだろ。
53:デフォルトの名無しさん
04/08/10 20:07
>>49
> S2の作者の会社(電通国際情報サービス)で、有償サポートの検討開始だってさ。
そのうち「S2認定技術者試験」みたいなもんもはじめたりして。
54:デフォルトの名無しさん
04/08/10 21:22
上のほうで絡んでるヤシは正にそういうのが欲しいんじゃないの＞認定
何かオプソ使うの好きなタイプじゃなさそうだし認定なら当然ドキュメントとか出てくるだろうし
55:デフォルトの名無しさん
04/08/10 22:22
>>30
> 反対に受託とかで、毎回違うものを開発しているところはS2のメリット無いでしょ。
> 単に作って納品するだけなら、S2を使わない方が速い。教育のコストもあるしね。
お前は仕様が完全に固まってから作れるのか。うらやましいぞ。
仕様変更のときにこそDIは便利なんだがな。お前触ってないだろ。
別にS2でなくてもいいからDI触ってみろ。Picoとかわかりやすいぞ。
56:デフォルトの名無しさん
04/08/10 23:11
>>53
> そのうち「S2認定技術者試験」みたいなもんもはじめたりして。
で、その前に認定試験対策研修が開催されると。
57:デフォルトの名無しさん
04/08/11 00:45
恐ろしく具体的な話の出ないスレだな
58:デフォルトの名無しさん
04/08/11 00:57
使ってない人間ばかりだからだろう。使ってる人間は来てないようだな。
59:デフォルトの名無しさん
04/08/13 17:04
>>41
サイトのトップページで「優しさや易しさを重視」って書いてなければ問題ないんだが。
と思ったら、「優しさや易しさを重視」の記述なくなってるね。
じゃあ、問題ないよ。
それより、Springがある状況で、Seasarにどういう価値があるのかよくわからないんだけど。
60:デフォルトの名無しさん
04/08/13 20:23
ソースのインスタンス変数名の"_"がイヤ。
あとは完結でいい
61:デフォルトの名無しさん
04/08/14 01:39
>>59
> それより、Springがある状況で、Seasarにどういう価値があるのかよくわからないんだけど。
WebSphereやWebLogicがある状況で、JBossにどういう価値があるのかわからん、といってるのと同じだよ。
それはさておき、DIという一種のパターンに対して、実装の形はいろいろあるってことだな。
SpringはBeanにこだわりすぎて結果として色んなものがどんどん密結合していっていると漏れは感じる。
S2はバラバラであることとつなぎやすさを優先している。理念と現場の違いじゃないかな。
両方触れば実感できることだ。トップページごときをとやかく言う前にどっちもダウンロードして触ってみろ。
ここはプログラム板のはずだ。Spring以外にもHiveMindやPicoContainerとか触ってみてくれ。
個性の違いを感じられると思う。DIの面白さを実感してみてくれ。
62:デフォルトの名無しさん
04/08/14 07:24
JBossはフリーだし、AOPも楽しそうだし。
なんか、Springでできることをやりなおしてる感じだと思ったんだが。
できることの違いじゃなくて、やりかたの違いなのか。
それにしても、ここまでドキュメントがないと、実際に使うのは怖いな。
仕様がないので、いつ使い方が変わってもおかしくない印象。
ソースとか見ればメソッドはわかるけど、それってメンテナンスで変更されたりしないの？みたいな。
63:デフォルトの名無しさん
04/08/14 08:21
>>62
ほとんどの機能はドキュメントで説明されているはず。
記述が足りないところはあると思うけど。
なんで、ドキュメントがないといいきっているのか分からん。
64:デフォルトの名無しさん
04/08/14 12:40
>>62
> 仕様がないので、いつ使い方が変わってもおかしくない印象。
そうだね。
J2EEみたいにSpecificationがあって、それに沿った実装が開発されているわけじゃないしね。
そういうリスクを取ってでも取り組む価値があるかどうかは、人によりけり。
65:デフォルトの名無しさん
04/08/14 12:47
>>62
> JBossはフリーだし、AOPも楽しそうだし。
S2もフリーだし、S2のAOPは楽しいですよ。
> なんか、Springでできることをやりなおしてる感じだと思ったんだが。
> できることの違いじゃなくて、やりかたの違いなのか。
それをいったら、Geronimoとかどうするんですか（ｗ
> それにしても、ここまでドキュメントがないと、実際に使うのは怖いな。
> 仕様がないので、いつ使い方が変わってもおかしくない印象。
> ソースとか見ればメソッドはわかるけど、それってメンテナンスで変更されたりしないの？みたいな。
ドキュメントのあるなしとメソッド変更のはなしは別でしょ。
Java自体だってそういうことはあるわけだし。
66:デフォルトの名無しさん
04/08/14 12:49
S2に限らず、DIって今のJ2EEでの開発に困ってないなら別にいらないよ。
今の状況に困っているなら、解決策のひとつとして検討する価値はあると思う。
67:デフォルトの名無しさん
04/08/14 12:52
>>64
> J2EEみたいにSpecificationがあって、それに沿った実装が開発されているわけじゃないしね。
> そういうリスクを取ってでも取り組む価値があるかどうかは、人によりけり。
そうだね。別にS2だけじゃなくて独自規格って多いしね。
共通規格がないものは使わないっていうのも大切だと思うよ。
S2はSpring同様にAOPアライアンスに準拠しているっていうけど
AOPアライアンス自体が公的な機関じゃないしね。
68:デフォルトの名無しさん
04/08/14 12:56
>>63
> >>62
> ほとんどの機能はドキュメントで説明されているはず。
> 記述が足りないところはあると思うけど。
> なんで、ドキュメントがないといいきっているのか分からん。
そうだね。そもそもS2って機能が少ないから、あれで一通りの説明にはなっている。
言葉足らずのところはあるかもしれないが、サンプルのコードとあわせて読めば
実際に使うのに必要なことはわかるよ。
>>62が気にしているのは、どんな風に使えばいいのかってことなのかもしれないね。
でもそれってSQLのマニュアルを読んで「プログラマのためのSQL」みたいな書籍に
書いてるようなことが書いてないじゃないかっていってるようで、ちょっと違うんじゃないかと俺は思う。
69:デフォルトの名無しさん
04/08/14 13:14
>>67
> 共通規格がないものは使わないっていうのも大切だと思うよ。
そこでC#でつよ！ dotNETマンセー！！
70:デフォルトの名無しさん
04/08/14 14:20
>>68
> >>62が気にしているのは、どんな風に使えばいいのかってことなのかもしれないね。
> でもそれってSQLのマニュアルを読んで「プログラマのためのSQL」みたいな書籍に
> 書いてるようなことが書いてないじゃないかっていってるようで、ちょっと違うんじゃないかと俺は思う。
うん。そう思う。現状S2のドキュメントって「何ができるか」が中心で、「どう使えばいいか」みたいな
ところまでは行ってない。だから使い手の力量が問われる。もっともその辺は有志(?)も気が付いて
いるはずで、サンプルプログラムの開発が進んでいる。単に使い方を知りたいという人は、それが
出てきてからでも良いんじゃないかな。始めるのは。
71:デフォルトの名無しさん
04/08/14 14:20
>>62
> それにしても、ここまでドキュメントがないと、実際に使うのは怖いな。
少しでも実際に触ってみた？ 何か全然S2を触ってないように見えるんだけど。
72:デフォルトの名無しさん
04/08/14 14:31
>>68
逆で、「プログラマのためのSQL」みたいなHOW-TOは書いてあるけど、「SQLのマニュアル」がない。
73:デフォルトの名無しさん
04/08/14 14:35
えーとね、ソースをざっとみたところ、
フレームワークはほとんどinterfaceと実装クラスの組からできているので、
仕様の大幅な変更は少ないと予想できる。
実装の変更はあるだろうが。
で、S2のコア部分はシンプルなことしかしていない。
色んなクラスへのアクセス方法とライフサイクル管理、Weaving、これらを提供するのみ。
便利なコンポーネントは作ったのだが。
じゃあどうやってそのコンポーネントにアクセスするの？
ファクトリクラス？するとファクトリの作り方がコンポーネントごとにばらばらになっちゃうね。
JNDI経由？するとレジストリにコンポーネントを登録するのは何が担当するのかな。
コンポーネントの処理を変えてみたいんだけど、ソース改変はバグの元だね。ソースなかったりするし。
というのを、ぜんぶS2が面倒見ますよん、というわけ。
コンポーネントを取得したあとは、それぞれの作法に従ってクライアントコードを実装するだけ。
74:デフォルトの名無しさん
04/08/14 15:11
ま、Seasarはドキュメントを軽んじてるから、このままじゃ大きく普及するのは難しいだろう、と。
大きく普及することに意味があるかどうかは別として。
75:デフォルトの名無しさん
04/08/14 15:17
もまいは使わんでよろしい
76:デフォルトの名無しさん
04/08/14 15:50
何か妙にドキュメントのことばかり話題になっているが
マニュアルの不備を指摘してる人は
S2の技術的なことについてはどう思ってるの？
77:デフォルトの名無しさん
04/08/14 16:29
ドキュメントがちゃんとしてないと使えないくらいS2は複雑だっていいたいのかな？
それともドキュメントさえ整備されればS2がもっと普及するのに勿体無いっていいたいのかな？
78:74
04/08/14 16:54
>>77
後者。
せめてJavaDocとDICONファイルに何がかけるかのリファレンスは欲しい。
79:デフォルトの名無しさん
04/08/14 19:46
見てみたらソースにコメント全然ないね。。。
80:デフォルトの名無しさん
04/08/14 20:19
Aspect関連のクラスにちょっとだけ日本語コメントがある
81:デフォルトの名無しさん
04/08/14 22:07
コメントも含めて何でそんなにドキュメント話ばかりなんだ？
他にもっとネタはないのかよ
82:デフォルトの名無しさん
04/08/14 22:30
>>81
> コメントも含めて何でそんなにドキュメント話ばかりなんだ？
普通の人にとってドキュメントは使い物になるかどうか判断する大切な材料の一つだから。
「今あるドキュメントで十分だろ」という人は、そういうことに気が付かない。
もっともそういうことを気にする立場ではないから、そう思って当然なんだけどね。
83:デフォルトの名無しさん
04/08/14 23:40
今はまだ「分かってる人が使える」存在のもの。
EarlyAdopterがそれこそS2に限らずPicoContainerとか色々試してる段階。
俺みたいに、仕事で使うには標準であることのメリットが甚大だという理由でEJB3.0を待っている人間もいる。
ドキュメント整備は、それこそ普及戦略の上での問題だな。
もちろんもっとあったほうがいいというのには同意。
ドキュメントがあろうがなかろうが、いわゆる「厨」は一定比率は発生してしまうがな。
84:デフォルトの名無しさん
04/08/15 00:42
実務優先でやってるから、ドキュメントより実装が先ってのは分かる。
ちょっと前の大きな仕様変更で痛い目見たんだが、ドキュメントが沢山
あるとああいう場合に大変だよね。
だからドキュメントが必要最低限なのかなーと思ったりする。
便利なのは間違いないんだけど、現状じゃあんまり他人に勧められん。
コアの部分が大きく変わることはもう無いんじゃないかと思うけど、
あったら辛いしなあ。
85:デフォルトの名無しさん
04/08/15 03:22
ミドルウェアを標準先決めで作ると、CORBAみたいな恐竜が出来上がることがしばしば・・・
そういう意味では仕様文書を整えるよりも実装＋HowToを先出しするという方針もありだとは思うけど、確かに現状で手を出すのはちょっと怖いような。
86:デフォルトの名無しさん
04/08/15 04:57
>>84
一応、ひがさん本人は、もうコアの部分に大きく手を入れることはない、と言ってるしね。
87:デフォルトの名無しさん
04/08/15 05:01
チュートリアルで、とりあえず使うことはできるんだけど、リファレンスがないから
「できないことがわからない」
機能を網羅したリファレンスがあれば、設定項目に用意されてないのが確認できれば、できないというのがわかる。
もちろん、設定を組み合わせて実現するようなものは簡単に「できない」というのはわからないんだけど。
88:デフォルトの名無しさん
04/08/15 09:39
よくもまあこんなに無内容な長文をダラダラと書き続けられるもんだな
89:デフォルトの名無しさん
04/08/15 10:21
>>83
今のEJBも標準だけど、使えないわけだが。
EJB3が使えるようになるのはまだまだ先。
使えるものになるかも分からないしね。
重要なのは今何を使うかじゃないの。
90:デフォルトの名無しさん
04/08/15 11:27
>>21
> チュートリアルだ。少し古いバージョンだが使えるだろう
> URLﾘﾝｸ(www.wikiroom.com)
最新のS2.0.15では、いきなり最初のプログラムが例外発生で動かない。
(「要素タイプcomponentsは定義されていません」...)
原因は
・list03-4. car.xmlにDOCTYPEがない
・classpathに通すjarが違う(log4j-1.2.8.jar, ognl-2.6.5.jar, s2-framework-2.0.14.jarなら動く)
ため。
全体的には
> ここもわかりやすい
> URLﾘﾝｸ(garbagetown.zive.net)
こっちの方が親切かな。eclipseベースでどういった操作をするか細かく書いてあるし。
でもdiconファイルの書くのにXMLBuddyつかうのは冗長な気がする。
単にコピペさせればいいと思うけど。
91:デフォルトの名無しさん
04/08/15 23:06
>>90
× s2-framework-2.0.14.jar
○ s2-framework-2.0.15.jar
だろ。
92:デフォルトの名無しさん
04/08/16 01:28
縮小再生産を作っておいて「Springには負けない」とか言われてもね。
まあその発言が勇み足だったとして、そもそも真似してる先人を全く
リスペクトする気が無いみたいで、Springのここがだめだとか、作者を
からかうような書き込みとかばかりだし。そういう文化、体質が本当に嫌だ。
組織として責任を持つプロダクトならばともかく、オープンソースな
ソフトウェアは、そういったコミュニティに対する印象も使うかどう
かに大きく影響してくると思うんだが、そういう自覚は全く無いみたいだな。
もちろん全員とは言わないが。
93:デフォルトの名無しさん
04/08/16 02:52
コミュニティーの印象がどうであれ、良いプロダクトであれば、使うと思うけど。
あと、先人じゃなくて、ほぼ同じ誕生日だし。
S2で言っているType4を、後から取り入れたのは、Springだし。
その辺は、どっちも、どっちじゃないか？
まず、プロダクトの事実をちゃんと見たら？
94:デフォルトの名無しさん
04/08/16 03:43
>>92
要するにS2のコミュニティに粘着したいだけだろオマエ
実際にどれだけ触ってるんだ？ オマエの好きなSpringについても
S2の作者より触ってないんじゃねえの？
Springを引き合いに出すなら、具体的な比較とか書いてくれよ
長文の癖に技術的な話が全然ないしうざすぎるよ
そんなに粘着したいならマ板に逝け
95:デフォルトの名無しさん
04/08/16 03:47
Springの話題はこちらでどうぞ
ｽﾚﾘﾝｸ(tech板)l50
96:デフォルトの名無しさん
04/08/16 03:57
>>92は当然これを読んでるんだろうから技術的なネタだしてくれよ
まあ正直この表紙はからかいたくなる気持ちもわかるがな
URLﾘﾝｸ(www.amazon.co.jp)
97:デフォルトの名無しさん
04/08/16 04:14
しかし絡んでる奴すごいな。いつもドキュメントかコミュニティのことばかり。
他に何にもないのが気持ち悪い。しまいにはストーカーになるんじゃないか。
98:デフォルトの名無しさん
04/08/16 04:22
>>97
実装の大変さを分かってる人は無言実行タイプが多いからここには書き込まない。
99:デフォルトの名無しさん
04/08/16 09:54
ひょっとして熱烈なSpringファンが絡んでるのかと
思ったがあまりの内容のなさにそれじゃSpringが
可哀想だと思った
100:デフォルトの名無しさん
04/08/16 11:21
100ｹﾞﾄ
101:デフォルトの名無しさん
04/08/17 07:11
>>97
モノはいいんだから、ドキュメントどうにかしろ、っていってるんだよ。
102:デフォルトの名無しさん
04/08/17 10:09
>>101
> モノはいいんだから、ドキュメントどうにかしろ、っていってるんだよ。
どのへんがいいのさ？
103:デフォルトの名無しさん
04/08/17 12:33
国産でオープンソースなところ
104:デフォルトの名無しさん
04/08/17 19:02
質素で日本的なところ。
105:デフォルトの名無しさん
04/08/17 23:55
質素というのは言い得て妙かもしれない。
良い意味でDIコンテナ部が全てだしな。
106:デフォルトの名無しさん
04/08/18 00:30
コンテナ部のドキュメント書き直されてるじゃん。
2chの無責任な書き込みにもちゃんと反応するのにビックリした。
いい人じゃないか作者さん。S2応援したくなってきたよ。今晩触ってみる。
107:デフォルトの名無しさん
04/08/18 00:49
ドキュメントドキュメントっていうけど
PowerPointの奴わかりやすかったけどなあ
108:デフォルトの名無しさん
04/08/18 08:11
>>106==>>1==社員乙
109:デフォルトの名無しさん
04/08/18 08:47
>108
（´д｀）?
110:デフォルトの名無しさん
04/08/18 21:41
>>106
かなりまじめに見てるらしい。
それを知ってるので、厳しいことかいてますよ > ひがっち
111:デフォルトの名無しさん
04/08/18 21:49
ひがっちっていうんだ
112:デフォルトの名無しさん
04/08/18 23:01
>>110
MLに投げればいいじゃん（ｗ
113:デフォルトの名無しさん
04/08/19 18:30
>>112
無責任に書きたいのでな。
114:デフォルトの名無しさん
04/08/20 11:12
最近責任のある立場ではっきりものをいえないへたれ日本人が増えてるよな。
２ｃｈが流行るわけだよ。
115:デフォルトの名無しさん
04/08/20 12:28
>>114
恥ずかしくない？
116:デフォルトの名無しさん
04/08/20 15:36
と無責任に意見をのべる114
117:デフォルトの名無しさん
04/08/20 21:11
で、藻前らぼちぼち技術的な話題はできないのか？
118:デフォルトの名無しさん
04/08/21 11:07
>>110
なんだ、かまって君だったのか
119:デフォルトの名無しさん
04/08/21 12:31
S2のコンテナ部分の特徴の一つにOGNLを使っていて、
SpringのPropertyEditorに相当する部分が不要な点が
あげられると思うんだけど、そのへんどうよ。
<arg>new java.math.BigDecimal(1)</arg>
みたいな。
120:デフォルトの名無しさん
04/08/21 14:32
>>119
> <arg>new java.math.BigDecimal(1)</arg>
どの位使う機会があるかわからないけど、便利なのは確か。
こっちの方が自然でわかりやすい。
121:デフォルトの名無しさん
04/08/21 17:47
>>119
Springのref,valueタグの役割をOGNLがやってるんだね。
122:デフォルトの名無しさん
04/09/02 01:06
EJBが難しくてよくわかんなかった俺でもS2はなんとか使い方がわかった。
くーすってやり方で設計してみたが、なんとか筋の通った設計書（らしきもの）ができた。
さて、あとはこのまま S2 で実装に落とせるかどうか。
自分が書いたシーケンス図を見ると、インターフェースやクラスにのっける機能が
明示されてるようにみえるけど、信じていいのかこれ。
123:デフォルトの名無しさん
04/09/02 08:21
>>122
やってから、また書き込め。
124:デフォルトの名無しさん
04/09/02 12:52
書いた本人が信じないで誰が信じるんだよw
でも考えてみりゃソフトウェアって書いた人間が一番信じてないことがよくあるな。
125:デフォルトの名無しさん
04/09/04 11:01
>>122
よく読むと不思議な文章だな（ｗ
よくわからないけど設計が出来てしまうのか
設計って考えながらやるもんだと思うんだが
126:122
04/09/06 22:41
実装始めたけど初手から躓いた。ドキュメントとサンプルを睨みつつ七転八倒。
結局ＤＩを理解してなかったことに２日かかって気づく。頭わるすぎ orz
なんというか、歴史あるクラス先輩に対して「そんな依存性は修正してやる」と殴りかかってる感じ。
で、さぁやってやるぞとS2Dao組み込んだら、Tomcat 起動中に s2containor の Servlet#init() で例外。
原因分からず。先が長そうでちょっと泣けた。
127:デフォルトの名無しさん
04/09/07 01:33
ガノタかよ（ｗ
128:デフォルトの名無しさん
04/09/07 06:29
>>126
例外が出たなら、トレースを見れば分かりそうな門だが。
diconファイルがどっかまちがってるんでしょ。
kijimunaを使いなさい。
URLﾘﾝｸ(sourceforge.jp)
129:122
04/09/08 20:12
Servlet#init() での例外、原因判明。
S2DaoのBEANアノテーションが内部クラス扱いになって別の.classファイルが作られてた。
で、それを JBuilder が war に入れないでやんの。関連チェック、デフォだと外れてるのか orz
そんなこんなで、やっと JBuilderX で S2 + S2Struts + S2Dao が動いた。
これ幸せかも。なんだかソースがとってもキレイ。
もう少し作りこんでからまた。
130:デフォルトの名無しさん
04/09/10 00:02
S2Tapestryの情報って無いですね。
ドキュメントもしっかりしてないので苦労してます。
131:デフォルトの名無しさん
04/09/10 08:14
ソース嫁っていうポリシーだから。
132:デフォルトの名無しさん
04/09/10 08:39
>>131
マンドクセー
そんな時間掛ける気ねーよ。
はやくS2JSFでねーかなー。
そっちならソース読んででも習得したいな。
133:デフォルトの名無しさん
04/09/10 11:19
どういうことで苦労しているのかを書けばいいんじゃないの？
134:デフォルトの名無しさん
04/09/10 11:20
使い方を調べるのに苦労します・・・とか？
135:デフォルトの名無しさん
04/09/10 14:24:29
>>133
つーかさあ、JavaDocで作成したドキュメントぐらいはねーのかよ！
136:デフォルトの名無しさん
04/09/10 15:00:17
>>135
コメントもありません。
137:デフォルトの名無しさん
04/09/10 18:15:38
S2タペのサンプルなんて足し算するだけじゃねーか！
もっと実用的なサンプルねーのか？
TapestryとS2Tapestryのアプリケーション作成時の違いってこれだけ？
あとはTapestryのドキュメント読んで作ればいいのかな？
・S2ContainerServletの設定 (web.xml)
・エンジンをS2用に変更 (*.application)
・ページ仕様にサービスの定義追加 (*.page)
・ページクラスにコンポーネントのプロパティを追加して
サービスメソッドを呼び出す (*,java)
138:デフォルトの名無しさん
04/09/10 19:02:44
依存性注入、っていうのがやっぱり今ひとつピンとこないんだが、
要は「論理設計（インターフェース設計）先行で開発せよ」ってこと？
くーすでやってると、まずインターフェースを書かないとなにも出来ないんで、
「とりあえず動くものを書け。話はそれからだ」っていうのを禁止してる感じがする。
139:デフォルトの名無しさん
04/09/10 21:23:33
>>135
getContainerするくらいだけなんだから
使うだけならJavaDocなくても困らん気がする
漏れはJavaDocが欲しいと思ったことはないな
サンプルは欲しい気がするけど
>>137
S2TapeはTapestryからS2を呼びやすくしてるだけだから
実用的なサンプルはTapestryのスレで聞いたほうがいいと思う
Tapestryについて語ろうよ！
ｽﾚﾘﾝｸ(tech板)l50
>>138
くーすは仕様先行で設計しようってだけだろ
別にDIでなくてもこういう考え方はありだと思う
140:デフォルトの名無しさん
04/09/10 22:21:02
さんぷるがほしいな。
S2Tapestry ＋ S2Dao
で、フレーム、セッションオブジェクトをバリバリ使ってるやつがいいな。
141:デフォルトの名無しさん
04/09/10 22:36:58
>>139
>別にDIでなくてもこういう考え方はありだと思う
それはそうなんだけど。「依存性を注入する」って、注入先を先に用意しないと成り立たない。
その注入先がインターフェース。この場合のインターフェースの役割って、業務システムのフレームワークでしょ？
それってつまり、DI で業務システムを組むってことは、詳細設計なき実装を不可能にする手法なのかな、と思ったわけ。
・・・作った後から仕様書書いたら切腹？
142:デフォルトの名無しさん
04/09/10 23:11:36
>>141
詳細設計なき実装が不可能？
おかしくないか？ 手続きのみの言語じゃあるまいし、設計書が無くても
コード書く前に普通、クラス構造は頭に思い浮かべるだしょ。
143:デフォルトの名無しさん
04/09/10 23:44:47
>>141
すまん漏れには何を言ってるのかよくわからん
DI関係なく藻前がどんな風に普段作ってるのか
教えてくださらんか？
144:デフォルトの名無しさん
04/09/10 23:46:05
>>140
フレームやセッションオブジェクトをバリバリ使うとS2は関係ないと思われ
145:140
04/09/11 00:30:55
>>144
TapestryでのFRAMESETの扱いや（S2とは関係ないけど）、
認証関係でセッションオブジェクト使って、
AOPで認証チェックやってるS2Tapestryのサンプルが見たいです。
ところでS2TapestryにすることでS2Daoの扱いが変わる（使いやすくなる）の？
146:141
04/09/11 02:46:18
>>143
Webは Struts で簡単な情報参照系しかやったことないので、
Windowsで作った受注出荷管理のときを例に。
１）システム機能仕様書、ERD、画面仕様書（レイアウトと処理内容、IO先）を同時並行に書く。
２）DB設計。
３）コーディング。複雑なロジックはコメントでクドクドと説明。
DBはデータ保障をトリガにおまかせ、SQLで気ままにアクセス。
基本的に１画面1クラスで機能を詰め込む。同系画面で継承は使うけど。
こんな感じ。
147:デフォルトの名無しさん
04/09/11 11:12:21
>>146
では次は 「DI は詳細設計なき実装が不可能」 と思った理由の説明を頼む。
ところで 1 画面 1 クラスってのは、どういう構造よ。
Action にビジネスロジック書いてるの？
それとも色々な Action クラスからある 1 画面の機能を詰め込んだサービスを
呼出してんの？
前者は推奨されてないし（10画面くらいのシステムなら別にいいとおも）、
後者はモデルの切り分けがおかしい。
で、同系画面では継承してる？
構造が分からないけど、サービスで切り出すのが綺麗だとおも。
継承では再利用性、メンテナンス性も低い。
148:デフォルトの名無しさん
04/09/11 11:39:06
簡単な情報参照系なら、Struts使う必要もないな。
149:デフォルトの名無しさん
04/09/11 13:02:27
作者、これまた大きくでたな。
URLﾘﾝｸ(d.hatena.ne.jp)
------------------------------------------------------
まずは、Nirvanaと組んだS2JSF。JSFは、リリースされたから結構経つのに、いっこうに
使われる気配がありません。これは、ツールベンダーの思わくが先行し、現場を見てない
結果だと思われます。
しかし、それも変わってきます。HTMLをテンプレートにし、DIコンテナと組みあわせる。
これなら、現場での使用にも十分に耐えられるでしょう。
くさったJSPなんかさよならです。重厚なEJBなんてさよならです。長いこと開発者を苦しめて
きた2つの技術。JSPとEJBに終止符を打ちます。
次は、S2Flex。時期的にはこっちの方が早く出ます。リッチクライアントも、試行錯誤の時期を
終え、いよいよ普及期に入ります。
2004年。これほど開発手法が激変する年は恐らくもうないのではないでしょうか。
150:デフォルトの名無しさん
04/09/11 13:32:35
開発手法の激変といっても、Javaローカルな話だね。
処理系依存。
151:デフォルトの名無しさん
04/09/11 14:13:21
まずは、DI を組み込んだ SeasarV2。 S2は、リリースされたから結構経つのに、いっこうに
使われる気配がありません。これは、作者の思わくが先行し、初心者に易しいを
ポリシーにしていたものの、実は初心者が理解できる代物ではなかったと思われます。
152:デフォルトの名無しさん
04/09/11 14:20:03
>>146
ロバストネス分析やシーケンス図を基にして「インターフェースを作る」ことを”詳細設計”と了解してる。
「設計」って考える作業でしょう。で、インターフェースって考えないと作れないから設計かな、と。
クラスそのままの引き写し構造でつくればいいってもんじゃないんでしょ。
インターフェースさえ作ってしまえば、あとは力仕事的にゴリゴリ書けそうだなと。
実装のうまい・へたはともかく「インターフェースの設計」のおかげで動きは保障されるだろうと。
お前はクラスを考えて作ったことが無いのかと問われると、たぶん頭の中でしかない。
せいぜい、主要部分のヘッダファイルを書くくらい。チームの時は実装担当者にお任せしてた。
んー。うまくまとまんないけど、DIの「構造と実装を分離する」ってのが、
・単なる実装レベルの一手段で、便利ツール的なものなのか、
・それとも設計手法に関わってくるほどのものなのか、
ってのが分かってないのかも。
>ところで 1 画面 1 クラスってのは、どういう構造よ。
勘違いされてるような。前述の例はWin32アプリ。具体的にはC++Builder。
細かい業務ロジックはフォームクラスに配置したUI部品のイベントハンドラに直書き。
重要な処理は private なメソッドに閉じ込めて、イベントハンドラから呼び出し。
たしか５０画面以上あるけど、その画面でやってることが基本的に１ファイルにまとまってて、
ほかの画面からも独立してるから頻発する改造に対応するには手っ取り早い。
Web だと通用しないかもしれないし、相当荒っぽいやり方だとは思うけど。
153:デフォルトの名無しさん
04/09/11 14:36:51
S2ﾀﾍﾟの作者もここ見てるね。
はてなに書いてたよ。
要望があれば書いてみれば。
メールしたほうがいいとは思うけど。
154:デフォルトの名無しさん
04/09/12 01:04:48
で、結局Springとどう違うの？
155:デフォルトの名無しさん
04/09/12 13:17:12
舶来か国産か
156:デフォルトの名無しさん
04/09/12 13:19:04
>>150
そうか？ .netだってSpring.netみたいなDI出てくるし
変わってくると思うけど
157:デフォルトの名無しさん
04/09/12 13:27:48
>>149に挙げられてるものはすべてJavaローカルなものだし。
.NETの人たちがMS以外のフレームワークを積極的に使うとは思えんし。
さらに言えば、コーディングレベルの話なので、本質的な変化ではないからなぁ。
仕事のやり方がかわるよりは、仕事に携わる人の種類・層が変わることの方が劇的な変化だから。
158:デフォルトの名無しさん
04/09/12 14:29:03
>>153
作者じゃないってさ。
ま、メンテナでもいいんだけどね。
確かにどうすれば普及するのかねえ。
なんかS2JSFが出てくると更に普及の可能性が低くなりそうな気がするね。
S2タペというよりはタペの話になってくるのかな。
しかしそのメンテナ曰く
＞＞そもそもドキュメントを読まなきゃ使えんと言うのが問題。
じゃ、どうやって使うんだろう？
今までマニュアルやリファレンス読んで作りながら習得してきたんだけど、
そのやり方には問題ありって事なのか？
もっと手っ取り早く習得できるやり方があるのなら大歓迎だけど．．．
159:デフォルトの名無しさん
04/09/12 14:35:28
補完してったらなんとなくわかる、ツールで適当にやってればできる、というのがいいということかな。
ドキュメントを精読しないと使えんというのは問題だろうが、だからといってドキュメントがないのも問題だな。
160:デフォルトの名無しさん
04/09/12 15:53:13
補完していくだけでセッション管理やトランザクション管理なんかが分かるフレームワークができればそりゃ普及するだろう。
というか、ウィザードで処理の雛形作ってくれるだけでも全然違うだろうね。。
つーか、そもそも補完する取っ掛かりが分からないからドキュメント見てるんだけど。
161:デフォルトの名無しさん
04/09/12 17:04:17
同様に、コメントなしでわかるプログラムが理想だが、だからといってコメントを書かなくてもいいわけではないな。
162:デフォルトの名無しさん
04/09/12 17:46:42
>>161
オブジェクト指向で書かれたプログラムでコメントなしってつらくねー？
JavaDocでもなんでもいいからオブジェクトの説明ぐらい要るだろ？
163:デフォルトの名無しさん
04/09/12 18:57:54
>>162
だが、クラス名だけで出来る限り分かるようにすべきだ。
たまにコメントがなければ、さっぱり意味の分からないクラスを見かけるが。
164:デフォルトの名無しさん
04/09/12 20:13:18
JavaDocは仕様を書くところで、
実装の説明じゃないから、
そこんとこヨロピク
165:デフォルトの名無しさん
04/09/12 20:16:38
>>163
英語分からない奴が無理やり英語の名前でクラス名つけたりするとそうなるよな。
わかんねーなら日本語をローマ字記述でクラス名書け！つーの。
166:デフォルトの名無しさん
04/09/12 22:00:38
しかし、KensyuとかHuriwakeとかHojyoとか、許せないローマ字はやめてほしい。
167:デフォルトの名無しさん
04/09/12 22:12:34
>>166
訓令式は知ってるよな。
168:デフォルトの名無しさん
04/09/12 23:30:06
>>166
S2と関係無いと思うんだけど。
169:デフォルトの名無しさん
04/09/13 00:32:58
もうね、jyoだけはやめて欲しいよ。
170:デフォルトの名無しさん
04/09/13 00:43:55
>>167
英語と混じるとはげしく違和感のあるローマ字記述法ですね？
171:デフォルトの名無しさん
04/09/13 13:16:21
>>170
英語と混じれば違和感あるのはどっちも同じ。
172:デフォルトの名無しさん
04/09/13 14:18:17
>>151
そんなあなたにEJB
173:デフォルトの名無しさん
04/09/13 14:54:00
英語に出来ない業務用語って多くね？
174:151
04/09/13 14:57:39
>>172
EJB は問題外です。今更 EJB 3.0 では DI や AOP と取り込んで
すばらしいものになりますってか。しかも 2.0 まで利用者の怒りが怖くて
互換性を残すと。金儲けする人も大変ですね。
175:デフォルトの名無しさん
04/09/13 14:58:40
EigoNiDekinaiGyomuYogo?
176:デフォルトの名無しさん
04/09/13 20:26:38
>>174
そんなあなたにドットネット
177:デフォルトの名無しさん
04/09/13 22:26:30
S2TapestryってAOPで認証チェックとかできるのですか？
そんなサンプルあれば欲しいです。
InterceptorでVisitオブジェクトをgetするために、
MethodInteceptorインターフェースを実装させてBasePageクラスを継承させるの？
なんか変ですよねえ。。。
どうすればいいのか教えてください。
いちいち、Pageクラスで認証チェックするのは手間です。。。
AOPじゃなくてもFilterとかでうまくできるのでしょうか？
178:デフォルトの名無しさん
04/09/14 01:28:11
>>173
「領収書」とかね。
179:デフォルトの名無しさん
04/09/15 00:24:00
>>178
receipt じゃだめなの?
180:デフォルトの名無しさん
04/09/15 00:28:21
>>179
じゃあ、「レシート」は？
181:デフォルトの名無しさん
04/09/15 00:36:08
日本語→英語→カタカナ
にしたときに違う意味になってしまうものは困る。
え、スレ違い？
話題ないんだからいいじゃん。
182:デフォルトの名無しさん
04/09/15 07:02:51
>>181
だったら>>177に答えてやれよ。
>>177
どうやらS2TapestryのPageクラスではAOPは使えないらしいぞ。
Tapestryは使ったこと無いけど、昨日のひが氏の日記に書いてる。
183:デフォルトの名無しさん
04/09/15 07:21:38
Tapestryは内部的にオブジェクトを生成するので、S2でインスタンス生成を握れない。
だからouterでDIを使うことはできるけど、S2AOPは使えない。
認証部分をS2から取ってくるコンポーネントに任せればいけるかも。
やったことないからわからんけど。
それでできるなら、もちろん認証部分のコンポーネントはDI可能。
184:デフォルトの名無しさん
04/09/26 23:22:30
そろそろS2JSFでる頃かな？
期待age
185:デフォルトの名無しさん
04/09/27 11:41:06
S2JSFは期待したいね。Kijimunaも良くなってきたから楽しみだ。
186:デフォルトの名無しさん
04/09/28 09:55:02
そもそものJSFのオープンな実装って出ないのかなぁ。
187:デフォルトの名無しさん
04/09/28 09:58:59
ともあれ、こういったコンポーネントはSpringの方が充実していくだろうから、オレとしてはSpringでDICONが使えるようにして欲しい。
今みたいな、同じ役割のメジャー&めんどくさいフレームワークとマイナー&お手軽フレームワークが並列する状況どうにかならんもんか。
188:デフォルトの名無しさん
04/09/28 22:03:26
軽いフレームワーク -> メジャーになる -> 要望に応えて重量級になる
189:デフォルトの名無しさん
04/09/29 03:56:43
>>188
核の部分は変わらないし、OGNL使ってるから高機能だし、Springに比べてお手軽なのは変わらんと思うよ。
SpringでDICONが使えるようになってほしい。
もしくはSeasarでSpringXXXが使えるようになってほしい。
190:デフォルトの名無しさん
04/09/29 06:52:35
>>189
そのDICONってなに?
Spring固有の機能使ってなければ、SeasarでSpringXXXはうごくんじゃないの。
191:デフォルトの名無しさん
04/09/29 09:23:06
>>190
Spring固有の機能使うからSpringXXXなんだと思う。
192:デフォルトの名無しさん
04/09/29 20:24:15
なんかFlexに力入れてるからS2JSF遅れそうだね
193:デフォルトの名無しさん
04/09/30 00:04:59
その分S2Tapeが強化されそうだし気長に待ってもいいんじゃない？
194:デフォルトの名無しさん
04/09/30 01:02:37
Tapeなんて使いもはん。
195:デフォルトの名無しさん
04/09/30 07:05:56
>>189
その使いたいSpringXXXってどんなやつ?
196:デフォルトの名無しさん
04/09/30 15:49:43
>>195
SpringHibernateとかSpringDAOとかJSF Springとか、Seasarでも並行開発されているヤツ。
今後もSpringの方が先行しつつ並行開発されていくヤツ。
197:デフォルトの名無しさん
04/09/30 17:41:30
>>196
素直にSpring使うほうがいいんじゃないか？
198:デフォルトの名無しさん
04/09/30 19:58:14
>>197
そしたら、Seasarの存在意義が。
199:デフォルトの名無しさん
04/09/30 20:59:38
SpringXXXを使いたいならSpringを使うほうがいいだろ。
漏れはS2DaoのためにSeasarを使ってるし。
200:デフォルトの名無しさん
04/09/30 21:37:22
S2JSFがそのうち出てくるのに今更S2Tapeやる気は起きない。
YSFとかでも勉強しとくかな。
201:デフォルトの名無しさん
04/09/30 22:02:08
お前らの会話は訳が分からん。
今後は文章に含まれる英字の量は全体に対して1%までと
規定するから、厳守するように。
202:デフォルトの名無しさん
04/09/30 22:35:29
SeasarのSpringより優れている点ってどこ？
203:デフォルトの名無しさん
04/09/30 22:43:17
NirvanaとかMyFacesがあるでしょ ＞186
204:デフォルトの名無しさん
04/09/30 22:54:13
＞202
国産・マニュアルが日本語、イベントも国内
今のところ、S2本体のソースがシンプルで追えなくもない
S2DAOが凄い、一方でS2HibernateもありO-Rマッパーの選択肢がある
Flash、Flexといったフロントエンドへの対応が進み出している
blog、MLでダイレクトにひが氏やコミッタにリクエストや質問を投げれる、
且つ、即座に採用されたり、回答がある
今のところ、Springと比較すると学習がお手軽、Spring MVCなんかを
DIって何？ってな新人さんに説明するのは難しいかも
お客さんのオプソ懸念に対して保険として国内での有償サポが準備？
まだ提唱されて間もないが、くーすといった開発方法論が芽生え始めている。
205:デフォルトの名無しさん
04/09/30 23:34:25
>204
S2Daoは確かに凄い。SQLを使える人なら間違いなく感激すると思う。
DB周りのコードがほとんど消えてなくなるんで、なんだか騙されてるような気がしてくる。
くーすは考え方はすっきりしてて分かりやすいけど、いざ実装しようとすると困る。
Strutsでいうと、Actionクラス＝くーすのコントロールで実装してみて一応それっぽくなったけど、
「ロジック層が業務フローを制御する」って言われると、コントロールがStruts依存になってるから駄目っぽいし。
でもコントロールをわざわざActionクラスと別に書くなんて面倒くさいし。書けといわれれば書くけどさ。
広く使われるには、誰かがくーす用のFramework的なものを書かんと難しいんじゃなかろうか。
206:デフォルトの名無しさん
04/09/30 23:39:47
NirvanaってJSFタグ吐き出すだけだと思ってた。
実装もあるんだ。
207:デフォルトの名無しさん
04/09/30 23:49:09
>>204
SpringMVCはWebでは使う必要なさそうだね。
S2DAOとSpringDAOの違いってどうなの？
定数アノテーションっていうのはCayenneと同じでおもしろいと思うけど。
OGNLと定数アノテーションがSpringとの大きな違いなのかな？
WEB+DB PRESSに解説記事が載ってたけど、ムダに大きいデータ構造で、ムダに本質的ではなさそうな部分が長いサンプルに読む気が萎えた。
208:デフォルトの名無しさん
04/10/01 00:04:13
それにしても、オープンソースプロジェクトってある程度広まって使えるようになったころに、プロジェクト自体があぼーんするからなぁ。
あまり大きなフレームワークは使いたくないというのが本音だ。
Seasarも、某社が会社の事業としてサポートするような、法人としての取り組みができるようにしたほうがいいと思うな。
そのためにはSeasarで利益が出せるようなしくみが必要になるんだけど。
でも、そうしないと、オープンソースプロジェクトって長続きしないよね。
209:デフォルトの名無しさん
04/10/01 12:18:22
>>208
一応、電通国際情報サービスがサポートするらしいね。
ところで、S2Daoでディスクキャッシュ機能があるとか昔日記に書いてあったが、
どうやればできるの？
210:デフォルトの名無しさん
04/10/01 12:28:16
>>209
SpringやらSeasarは今後3年くらいかけて浸透するだろうから、機能をあわてて実装するよりも、プロジェクトが5年10年続くようにがんばってほしいな。
211:デフォルトの名無しさん
04/10/01 21:22:31
>>210
浸透ってのがどの程度を言ってんのか分からないけど、俺はなんか違うとおも。
例えば Web アプリと言えば、Tomcat や Struts は浸透してるとおもう。
これが 3 年後に Tomcat と Struts、んで DI コンテナは何？ ってなことにはならない希ガス。
汎用 DI コンテナはフレームワーク作成者や新しいもん好きが使うものであって
システム構築者には汎用的すぎる。特化してるっぽい S2xxx や Springxxx とか
あるけど、まだ DI 使うとこんなすごいことができるみたいなオモチャに見える。
DI コンテナが浸透するんではなくて、フレームワークやライブラリが DI を
使用するのは当たり前になり （DI は自前でも良いし、cglib、javassist、BCEL、asm
なんでもいい） DI を冠することも無くなり、開発者に意識させないと思う。
212:デフォルトの名無しさん
04/10/01 21:37:16
>>211
もちろん、DI+AOPは基盤技術になるわけだから、本来表に出るもんではないと思うよ。
オブジェクト指向のためにJavaを使うんじゃなくて、Javaって便利だけどこれってオブジェクト指向に基づいてるらしいよ、みたいな。
なんかめっちゃ楽なんやけど、これってDIとかAOPっていうもののおかげらしいで、と。
ていうか、使用するのは当たり前ってことは浸透してるということなんじゃないかと。
ただ、そのためには実装とそれに基づいた実用部品が必要で。
その実装として、今はSpringとSeasarがあるわけだ。
あと、DI自体は使うのが非常に楽で、使えば結構自動的にアプリケーションの多層化やら部品化ができるから、やっぱりその利点を認められて広まると思う。
AOPは、末端開発者が積極的に使うものというよりは、コンポーネント提供者が利用して、末端開発者は何も考えなくてよくなる、という仕組みだと思ってる。
AOPこそ、開発者に意識させないものだと思うな。
使う言葉が違うだけで同じことを言ってる気がしなくもないが。
213:212
04/10/01 21:56:03
そういえば、誰かDIconファイルを視覚化して編集するツール作ってるみたいだけど、あれってもうちょっと発展させたらなつかしのAPPGALLERYみたいになるね。
ありがちなビジネスロジックの呼び出し仕様を集めたインターフェイスを登録しておけば、そいつを視覚化したものを配置して、メソッドつなぎあわせればアプリケーションになる、と。
呼び出し先の引数と同じ型のプロパティ持ってたらそれを自動的に渡して、みたいな。
ダブルクリックしたらそこのソース編集とか。
よくない？
214:デフォルトの名無しさん
04/10/01 22:07:23
>206
スマソ、HTML2JSP、JSFのコンバータだった。
215:デフォルトの名無しさん
04/10/01 22:09:25
>209
キャッシュはまだ未実装な筈
216:デフォルトの名無しさん
04/10/02 11:52:35
>>213
懐かしいな。そうなるといいな。
217:デフォルトの名無しさん
04/10/02 14:11:49
>>205
Actionは、業務ロジッククラスの一つのメソッドを呼ぶだけに白ってことだから
そんなめんどくさいことないだろう。
これまでも、Actionにロジックをおくなって言われてたわけだから、
そんなにかわんないだろう。
218:デフォルトの名無しさん
04/10/02 20:13:54
ひが君の日記より
> 実装上は、バウンダリから呼び出されるメソッドは、インターフェースになり、
> コンポーネント内からしか呼び出されないメソッドは、実装クラスのpublicメソッドに
> なります。
> 内部からしか呼び出されないのに、実装クラスのpublicメソッドにするのは、
> テストをしやすくするためです。別にprivateメソッドでもリフレクションを使って
> 呼び出せますが、コンポーネントを使う方は、インターフェースしか見ないので、
> 特にpublicでも問題ないと思います。
内部メソッドを public にか。俺はこれをダサいと思わん神経を疑う。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5378日前に更新/285 KB
担当:undef