【Office2003？】リッチクライアント【Flash？】

次世代のリッチクライアントについて考えていきましょう

Office2003が最有力と呼ばれていますが、どうなんでしょうか？
現時点の候補はこれくらいでしょうか。

Office2003
http://www.microsoft.com/japan/office/editions/prodinfo/default.mspx

Flash
http://www.macromedia.com/jp/software/flash/

Biz/Browser
http://www.axissoft.co.jp/biz/bizbd/index.html

PDF
http://www.adobe.co.jp/products/acrobat/main.html

考えません

私は、Flashが最有力と考えています。

あれ、ぜんぜん盛り上がりませんね。

名スレの予感

お前らなんか書けよ、ハゲ

リッチクライアントって何ですか？

言葉通り金持ってるお客さんのことだよﾊｹﾞ

>>8
うまい！！

>>7
ブラウザだけでは実現が難しい機能とかを、
Flashとかで実現したものらしいよ。

とんだ糞スレだな

>> 1 ◆he61mp0qOM
レスありがと

>>7
ここに詳しい解説があります

＠IT リッチクライアント
http://www.atmarkit.co.jp/channel/richclient/richclient.html

1 ◆he61mp0qOM と同じく、Flashに注目してます

Flash+JAVAの実例
http://www.nttd-bb.com/solution/total/solution1/

私としては、この形態に注目中

WebがUIとしてクソなのは当たり前だが、じゃあFlashが生産性高いのか？

UIに面白さ求めてもしょうがない。

需要あるのは家電かゲームくらいだろ。

Web は UI が poor なのが良いと思ってるんだけどね。

Appletはー？

>>1
漏れもこの話題に興味あるのでがんがってくだされ

Webで揉まれたリッチクライアントはLightweightなGUIを駆逐する
とか考えているので

フリーでオープンソースなリッチクライアントってないの？

ノータッチデプロイメント

>>15
Appletがもう少し軽ければ良いんですけどね。
低スペックマシンを使っている顧客相手だと、実務には少し耐えられない気がします。

>>18
.NETのノータッチデプロイメントと
JavaのWeb Startも次世代リッチクライアントの候補だと言えますね。

.NET Framework のノータッチ デプロイメント
http://www.microsoft.com/japan/msdn/vs/deployment/vbtchno-touchdeploymentinnetframework.asp

Java Web Start
http://java.sun.com/products/javawebstart/ja/index_ja.html

うっすらWebProg板向けだとも思ってるんだけど実際どっち寄りなのだろう

SMIL,SVG,ECMAScript

なんどOffice2003とFlashとを比較されるんだ？
解説キボンヌ

>>22

ここに解説があります
http://www.atmarkit.co.jp/fwin2k/techreview/off2003dotnet/off2003dotnet_01.html

Office2003とFlashは若干用途が異なります。

.NETvsJAVAvsFLASHと言った方が良いかもしれません

Microsoft .NET Pet Shop
http://www.microsoft.com/japan/msdn/net/compare/bdasamppet.asp

Java PetStore
http://java.sun.com/blueprints/code/jps132/docs/index.html

Flash PetMarket
http://examples.macromedia.com/petmarket/flashstore_800.html

いまいち盛り上がらないな。

ブラウザ以上の表現力を顧客に要求された場合は
皆さんどうやっているんですか？

うちの顧客は直ぐにACCESSやVBのＣ／Ｓシステムとりたがる。

フツーのGUIの何が不満なんだ？


ガイドラインに沿うUIマンセー

そもそもこのスレで何をさせたいのよ。
技術名を列挙してるだけに見えるんだが。
信者同士に論争でもさせたいのか。

リッチクライアントといえば目立たないけどAcrobatもあるね
たしか５あたりからxmlやらDBやら実用的になってきてる
紙ベースの処理になれてる人は入りやすいんでないかい

方向性的には有料だし対抗馬はOffice2003あたりか


まぁ、スレ立てる場所まちがえてるような＞１

>>24
やだなー。
うちもそうだよ。

二日でこれだけレスが付けば上等だよ。
またーり良スレ期待age。

ちなみに、おいらはJava厨なのでWebStartに期待。

主流となるのはClickOnce〜Longhornの流れかな。

PDFのどこが立地クライアントなんだ？
紙に印刷するためにつくられたかのようなあれのどこが？

やはり板違いの気がしますので、WebProg板に引っ越しました

http://pc2.2ch.net/test/read.cgi/php/1079494830/

そう考えるとJavaや.NETの話題も全てWebProg板に振った方が良いのではないか？

>>31
一応入力も出来るし、ボタンも付けられるじゃん。
でもあれだな。
ブラウザと変わらんな。

>>34
現時点では、帳票を簡単に作成できるってのが強みだよね。
Flash Paperが多機能化してくれれば、PDFを上回ることも出来そうなんだが。

このスレもうすぐ終わりそう

つーか「○○について語る」スレはたいがい長続きしないか論争になって死滅スレになるかだよな。

ここでXMLの3文字が全く出てこないのがXMLの悲哀。

だからさ、なんてフツーのアプリじゃダメなのよ　そこを語れ >>1

>>39
>>1じゃないがそういう議論をするスレでは無いからじゃないのか。
Cスレで「なんでJavaじゃダメなのよ」と言ってるようなもん。

XML自体はリッチではないような

>>40

だって、>>1の定義だとリッチクライアントって気色悪いクライアントサイドアプリだろ

気色いいクライアントサイドアプリのほうがいいに決まってる

>>33
それは無理

>>42
なんだその気色悪いとかいいとかって。

>>42
もともとＣ／ＳからWebに移ったのは、
アプリケーション配布やバグ対応等の管理の容易さと
ユーザーインタフェースの統一だったんだが、
Ｃ／Ｓのときのインタフェースを覚えている顧客は
ブラウザでは我慢できない。
そこで、再びＣ／Ｓに戻るか、ていうと、そうではなくて、
Webでアプリケーションを管理して、ユーザーインタフェースはＣ／Ｓのときのような
利便性を、て考えるのが普通の流れだと思う。

配布が容易で、定期的に修正版を渡せる環境ならば、
クライアントサイドのみで動くアプリが良いに決まっている。

>>42を観る限り>>42はあまりよく知らないで文句たれてるような

何度も聞くが>>1はこのスレで何をしたいんだ？
>>1に「考えていきましょう」とあるが具体的に何を？
>>24を見ると客の愚痴を言いたいのか、客を説得する方法を考えたいのか、
いずれにせよ技術的な話では無いような気がするのだが・・・

まあ、これからの流れとしてリッチクライアントに行くのは自然だからなぁ。
このスレは価値があると思うよ。
PCなんてどんどん高性能化＆安くなってるもんな。

>>23に.NETvsJAVAvsFLASHとあるので論争させたいのでは。
でも皆興味が無いので論争にすらならないという現実。

リッチクライアントのキラーアプリでも無いと
一般人に認知させるのは難しいんじゃないか。

そういや@ITにノータッチデプロイメントのサンプルあったんだけど、
普段オフにしてるんで設定変える必要があった。
ActiveXの前例があるから常にオンにするのはちょっと怖い。

>>47
いや、いろいろ情報が知りたいだけ。

JavaScriptだけで対応しているとか、
Flash使ってみたけど、どうだったとか、
そんな体験談みたいなものを聞きたい。

客の愚痴とかでは無く、良い技術があったら
それを取り込んで、客に提案したいだけ。

>>52
それを>>1に書かなかったのは痛かったな・・・
確かにおもしろそうだと思ってる人はいると思うんだけど、
実際に使ってる人は少ないだろうから体験談を話せる人がいるかどうか・・・

>>45

自動アップデート機能付きクライアントサイドアプリが良いなら、
FlashだのPDFだの問題外だと思うのだが、

>>54
FlashもPDFもサーバからダウンロードして使うわけだが

>>55
あれはクソな開発環境しかないだろ

>リッチクライアントのキラーアプリでも無いと

2ch ビューアとかはリッチクライアントなのか？

それは普通のクライアントだろ。

極窓のようなアプリをリッチ(肥え太った)クライアントという。

肥え太ったクライアントにはファットクライアントという用語がすでにあります。
対義語はシンクライアントです。

WebアプリにてHTMLの代わりをするのがリッチクライアントじゃないのか？

・・・・・・・・ブラウザの代わりだろ・・・・・

別にブラウザの代わりにならなくてもいいよ。
HTMLよりリッチな表現・操作ができるクライアントアプリのことだから。

HTTPプロトコルとかで通信できればいいのか？

今HTTPで動的にアプリを構築するアプリを書いてる。
DLするのはﾏﾙﾁﾊﾟｰﾄでXMLと必要なDLLをﾀﾞｳﾝﾛｰﾄﾞ

> 必要なDLLをﾀﾞｳﾝﾛｰﾄﾞ
ｷﾀ━━━━(ﾟ∀ﾟ)━━━━ｯ!!

>>62
アプレットはどう考えるんだ。

金持ちの客がどうしたって？

>>65
知らないうちにクライアントの環境を破壊される予感・・・

リッチクライアントであろうと普通のクライアントアプリだろうと
開発環境が一番整っているのは.NETなんだよね。

InfoPath は衝撃的なプロダクトだと思う。

Java ﾏﾝｾｰ な人間だが、
フロントエンドを InfoPath で組んだエンタープライズアプリケーションなんて
ぜひ提案したいな。

WebをGUI代わりに使おうと考える時点でアフォ
操作中に中止、更新ボタンとか押されると破綻するし
進む、戻るも危険

>>71
とはいえ、Office2003の導入は提案しづらくありませんか？

>>72
それはただのWebアプリの話か？スレ違いってのはわかってるよな？

>>71

今までに無いタイプのプロダクトが出たのは確かに新鮮な感じはする。

しかし、Excelなんかだとデータと装飾が分かれていないのが元々、ソフトウェアのデザインとして
どうよってこと思ったし。
ようやく当たり前のことやりだしたんじゃないか。

（JavaScript等でも出来るんだけど、とりあえず無視して）
ブラウザへの不満として上げられるものは何がある？

俺が良く聞くのは次のもの

・ENTERキーで次の入力項目へ遷移
・カンマの付加、合計金額の再計算
・IMEの切り替え

画面の一部だけ書き換えることができないところ

>・ENTERキーで次の入力項目へ遷移
tab 使え

>・カンマの付加、合計金額の再計算
カンマなんて気にするな。どうしてもつけたいなら Javascript 使え。

>・IMEの切り替え
全角はアプリ側で補正しろ。

なにができないって、
Excelみたいにがーっとセルをコピーできないし、
選択したモノによってよけいなのがグレイアウトしないし、
タブもさくさく逝かないし、
絵も描けないし、
キーボードマクロもできないし、
狭い入力フォームを広くできないし、
よく入れるデータをたっぷり覚えてくれないし、いくらでも。

予想外に変な UI が作られたりしないのが利点。

つかリッチクライアントのスレだっつってんのになんでHTMLの話なんだよ

>>79
そこまで要求されるとOffice2003しかないな。

Office2003をクライアントにして、
Webサービスからデータを提供しようとする場合（InfoPath？)は
クライアント（データ加工）は基本的にユーザーに任せて、
Webサービス管理を行うアプリを作ったが得策のような気がする。

俺はOfficeをクライアントとして扱う業務アプリ作ったこと無いんだけど
あれをクライアントにすると制御するの大変じゃない？

>>82
おもいっきりユーザーのレベルに依存する。
がちがちに固める必要があるならC#なり、Officeと親和性の高い
ツールを使った方が早い。

実際にFlashとかJavaWebStartで業務アプリ組んだ人いないの？

そりゃいるだろ。

お遊びで内輪でやった奴はいるかも知んないけど、
ちゃんとした案件ではさすがにないだろ。

>>86
なんでよ。別に信頼性低くないぞ。普通のクライアントサイドアプリケーションだ。

リアルタイムの表示が必要な証券や為替とかは Flash 多いだろ。
バックは J2EE とか。
Javascript で表示を定期更新するまぬけなシステムも
たまに見かけるけど。

まぬけとか言うなよ！

J2EEにFlash？
イヤなものばっかだな

Flashはよくて、JavaScriptは間抜け七日よ。。
>>87
ASもWebStartもちゃんとした案件で使われるほど、
十分叩かれてないんじゃないのかな。そんなの気にしないのかな。
ホントは漏れだってそういうのやりたいし、Tigerだって使いたいが客がうんと言うはずもなく。

そういうものを提案できる程度の規模の会社に移ろうかと考えている。

ツールベンダが実際に何かしてくれるわけでもないのに「サポートが」「実績が」と言う輩が多すぎ。
クライアントに「できません」と伝えることになるという結果は同じなのに。

>>76
Javascript無視する理由が分からない。
Javascriptで全部出来る。

>>93
Javascript ON をユーザに強制できるシステムでは無いからじゃないか？

>>75
InfoPathも基本的にはデータと見た目が一緒になってるよ。
送信（Webサービスなんかへ）はデータだけ飛んでいくってだけで。

http://www.vistaprint.jp/
これってどうやっているのでしょう

リッチクライアントという意味ではスレ違いですが、リッチUIを提供するという手段としては、MetaFrameやGO-GLOBALなんかはいかがなもんでしょうか？

>>97
高いよ

日本で言うとこのリッチクライアントはUSでは廃れた模様。
・リッチインターネットアプリケーション(RIA)
・エンタープライズインターネットアプリケーション(EIA)
・スマートクライアント
といった言葉が浮上中らしい。

LaszloとかNexawebとかが代表選手らしい。
ともに大手の顧客獲得してるみたい。
Nexawebは日本でも事業展開しはじめてるようですね。

その対極のアプローチがMetaFrameとかですが、
サーバー上ではなくクライアントでアプリを実行するもので
SoftGridという製品があるらしい。

「リッチクライアント」という 言葉 がダサくなっただけで、
結局言い換えなんでしょ?

つーか、元々先にRIAって言葉が出てきて
それに乗っかろうとしたイントラなベンダが
リッチクライアントって言い出しただけだよ

シンクライアントって言葉があって、
それに対する言葉がファットクライアント、ってんじゃあんまりだ、ってんで出来た言葉だと思ってた。

ファットクライアントって､
普通？のクライアントアプリ（独自にサーバと通信するやつ）のことじゃないの？
うちの会社も、特定業務ではそういうＶＢアプリが顕在。

ファットクライアント＝リッチクライアント：
通常のクライアントアプリケーション。
機能的には申し分ないが、配布の面で何があり、
頻繁に更新されるものや、多数のクライアントＰＣにインストール必要がある際に難あり。

シンクライアント：
機能的には一部の制限を受けるが、
初回起動時にサーバからダウンロードされ実行、
以降は起動時にサーバへ更新を問い合わせ、
常に最新のクライアントアプリが実行される。

スマートクライアント：
ＭＳの提唱するシンクライアントとファットクライアントの中間層。
ＰＣ側にあらかじめランタイム（.NET Framework）がインストールされている環境で、
シンクライアント以上の軽快な動作と、充実したUIコンポーネントの実装を目指す。

ってイメージだったが。
ファットとスマートの間に、もう一層、リッチという層があった、ってことか。

リチクラ最有力候補としてCurlのクソ分厚い書籍が出てたけど。真相は？

真相って、あんたコナンかよ

>>105
プラグインが普及してくれないと、どうにもならんよ
当分は静観でいいだろう

・ファットクライアント（コンピュータ）
　ハードウェア的に高機能・多機能なコンピュータ。現在のPCなど。

・シンクライアント（コンピュータ）
　ハードウェア的に低機能（必要最小限）なコンピュータ。
　HDDやFDDを簡素化した、入出力を主とするクライアントコンピュータなど。

・リッチクライアント（アプリケーション）
　ソフトウェア的に高機能・多機能なWebアプリケーション。

・（従来の）クライアント（アプリケーション）
　ソフトウェア的に低機能（主にHTMLのみ）のWebアプリケーション。

Curlはモノがどうこう以前にプラグインに金かかるっていうのが萎えだったのだけど

プラグインにかねかかるのは
Biz
Curlはプラグインは無料。

確かにこいつらは104の言うとこのスマートとファットの中間
逆にスマートとシンの中間がNexawebのような気がする。

スマートクライアントはMSじゃなくてもともとはフォレスターあたりじゃないの？
Nexawebとかもスマートクライアントって言葉を使ってるしね。

日本で言うところのリッチクライアントは
HTML以上でクラサバ以下の機能と操作性を持ち、
WEBでアプリケーションを配信できるソフトウェアプラットフォームでしょ。

でその評価項目に
・実現可能な機能
・お値段
・プラットフォームの配布方法
・プラットフォームの動くためのOSやブラウザ等の制約
・開発生産性
・etc
ってことじゃぁないかと、、、

Nexawebはプラグインいらない模様！

http://www-6.ibm.com/jp/developerworks/java/040507/j_j-echo1.html
ここの話は既出?

スマート・クライアントの傾向と対策
―　Webアプリケーションの不満は解消できるのか？　―
日本ユニシス 猪股健太郎
http://www.atmarkit.co.jp/fdotnet/special/smartstrtg/smartstrtg_01.html

メディアがこんなこと言っていいのか？
>>113
まずはスマート・クライアントの定義を確認させてください。スマート・クライアントはマイクロソフトの造語ですが、本稿では、
「Webアプリケーションの利点である導入・運用の容易さを取り入れたクライアント／サーバ型Windowsアプリケーション」
のことをスマート・クライアントと呼びます。

ほれ
http://www.nexaweb.com/news110701.htm

スマートクライアントを勝手に定義スンナあほが

>>114
確かに最近この辺りが儲かるのか知らないけど、
自分達の都合に会わせて勝手に定義して、売り込んでいる企業が多いよね。

biz/browser の trial を取り寄せて、ちびっと使ってみた。
予想以上によさげでした。

業務システムのクライアントはこれでイイじゃん、と思うのだが
あまり広まってないみたいね。
プラグインのライセンスがフリーで、もうちょっと知名度が上がれば
お客に提案しやすいのだが。

>>116
値段がなー

>>104
>ファットクライアント＝リッチクライアント
>配布の面で何があり、
>頻繁に更新されるものや、
>多数のクライアントＰＣにインストール必要がある際に難あり。

これは違う．
ファットクライアントは，
ロジックをクライアント側にほとんど埋め込んでしまったため，
膨れ上がってしまったクライアント．
こいつは，配布性に問題がある．

リッチクライアントは，
・配布性の問題を解決した(Java Web Startなどで)
・ファットクライアントほど，ロジックが組み込まれていない
・ネットにアクセスできなくても動作する
などの特徴がある．

つまり，
ファットクライアント != リッチクライアント

迅速なデータ入力を必要とするC/Sアプリなんかにリッチクライアントって最適だよね
C/Sアプリとしては理想形だと思うが、どうなるんだろう

Java Web Startで全てが解決すると思ってたのですが、実際はどうなんですか？

.NETのアプリケーションはインストール不要でつか？

>>120
Javaは好きなんだけど、GUI作成が大変なんだよね。SWING重いし。
>>121
.NETノータッチデプロイメント使うのなら、クライアントにも.NET Frameworkが必要。
尚且つ、C/S並みの使い勝手を求めるなら、クライアントのセキュリティ設定も必要。

では、Java Web Start vs .NETノータッチデプロイメント
ではどっちが勝ちますか？

それともcurl？

携帯電話でJava Web Start出来待つか？

リッチクライアントは氏にましたか

フラッシュはなかなかいいけど仕様変更とかめんどくさそうだな。
あと、フリーのリッチクライアントとかってあるの？
Web Startとかか？Web Startだと作るのにコストかかりそうだけど・・・

コストかかっても、使いやすい椰子を探してるんですけど、
フラッシュで使いやすいサイトとかあったら教えて下さい。

Web Start使ってるサイトなんて多分Ｓ∪∩のそれもサンプルのサイトだけだろうな。

早くマクロメディアがＪＳＦレンダラ作ってくれればいいのにね。

Javaに使いやすいGUIビルダーがあれば、Web Startもはやるのかな？

JavaWebStart使ってるサイトは増えてきているよ。
JavaAppletの代わりだからね。Appletよりも自由度が高く細かいことができるので
需要はこれから大きくなると思われ。

>>130
実はJavaWebStart(･∀･)ｲｲ!!なんだけど誰も使ってなくて躊躇中。

そのサイト教えて下さい。

携帯機器でJavaWebStart使えれば大ハヤリすんじゃないかと思うんだが、mobile editionでしたっけ？どうなん？

企業などではF/Wで application/x-java-jnlp-file がsafe content typeになっていなかったり
するのが、復旧の妨げになってたりして＞web start

サクッと作れないのなら俺はHTML＋JavaScriptでがんばるぞ。

>>130
どこ？ちょっと試してみたい

リッチクライアントの対義語ってシンクライアントなんですか？

curlといえば
住商情報

>>136
対義語ではないみたい。

Webブラウザとかがシンククライアント
PC上に実装されたクライアントがファットクライアント
と書いておりました。

>>131 さんも公開汁！

JavaWebStart と curl は、
どっちが強いでつか？

>>121
スマートクライアントで。
結局、企業用クライアントとしてはJavaWebStartとスマートクライアントに別れていくだろうな。
一般向けエンターテイメント用途はFlashだろうがなんだろうが勝手にやってくれと。

>>141
スマートクライアント=.NET
リッチクライアント=JavaWebStart
なの？

この場合の、スマート／リッチ、ってのは何なんだ。

追加すると、
シンクライアント=Webブラウザ
ファットクライアント=ネイティブアプリ
なんかな。

>>142
スマートクライアントもJavaWebStartもリッチクライアントだろ。

>>142
シンクライアント・ファットクライアントというのはハードウェアの形態だから。

JavaWebStartってのはサーバ側に実行ファイルみたいな”.jnlp”ファイルを置いとくだけなんかな。
なら作るの超楽勝じゃん。

>>145
だいぶ違うぞ。

>>145
ファイルアクセスがなければね。
ただ、リッチクライアントはようするにクライアントなんだから、サーバーとのやりとりが問題になる。
　クライアント > サーバー > DB
の３層構造になるわけだからね。
で、Webサービスがシームレスに扱えるような開発環境が必要になるわけだ。

実行ファイルとは別に、JNLPおくんだが。
iアプリのjamファイルみたいな感じで。

>>147
JDBCは楽だけど禁じて、ってことなんだね。

>　クライアント > サーバー > DB
>で、Webサービスがシームレスに扱えるような開発環境が

この場合のシームレスとは何だろう。
HTTPで切れるんだから、片方をJar、片方をデバッグ実行だけで良いような気もしなくもない。

>>148
JNLPは起動だけなんだね。
でも、その後サーバに置いといたJarファイルがクライアントで動作するならEXEっぽくて分かりやすいかも。

みんなはクライアント＞サーバ＞データベースの
サーバ部分には何を使ってますか？servlet？

Webサービス以外の選択肢は実質ないと思うが。

>>149
Webサービスであろうが、ローカルクラスだろうが、ほぼ区別せずに作成できるような環境。

なるほどクラスがシームレスか。>>152

で、Java/RMIだとオブジェクトを丸ごとそのままクライアントに投げれるんだっけ？
ドキュメントクラスみたいなのをサーバでロードして、クライアントに丸投げ出来れば楽々作れそうだね。

ようするに、クライアント側をサクサクッとリッチに作りたいんですよ。

>>154
お金をかければ可能なんじゃない？
CurlとかBiz/Browserとか。
でもインターネットで不特定多数向けに公開するとなると、
Java以外選択できないんじゃないの？

>>155
むしろFlash

JavaWebStart vs .NETのノータッチデプロイメント
かな。

.NETは嫌いなんだけど、.NETノータッチデプロイメントは試してみるかな。

で、.NETノータッチデプロイメント のサイト希望。

解説からテストアプリまであるサイト！

>>156
確かに。
でも個人的には使いたくないな。＞FlashとPDF
食わず嫌いはｲｸﾅｲけど。

とりあえず、URL指定してActiveXを落として、
実際のEXEの圧縮ファイルをサーバから取って解凍起動したいんだが、
そんなActiveXは無いでつか？

JavaWebStartを使っている例（2chブラウザだけど）
ttp://v2c.s50.xrea.com/

>>161
ﾒﾁｬｶｺｲｲ

速いし、もうﾄﾞﾄﾈﾄ炒らないかも。
ttp://v2c.s50.xrea.com/V2C_512M.jnlp
ttp://v2c.s50.xrea.com/V2C_256M.jnlp
ttp://v2c.s50.xrea.com/V2C_128M.jnlp

>>162
あまり宣伝しまくると、Java厨と呼ばれる・・・
J2SE5で使うのがいいね。

とりあえず.NET版の実例も見てみたい。
誰か知ってる人いませんか？

JavaWebStart は凄いアプリ出来てるんだから、
.NETノータッチデプロイメント も実例出せ！

>>161
その開発環境というか、ソースは公開されてないのかな。
classファイルは取り出せたが、NetBeans IDEでは逆コンパイル出来ないＹＯ！

>>164
知ってます。

>>167
これのことだろ。
--------------------------------------------------
.NET Framework のノータッチ デプロイメントに期待して、
サンプル置いてるサイト実行したら、
>IEExec.exe - 共通言語ランタイム デバッグ サービス
>処理 ID=0x9bc (2492)、スレッド ID=0x6f0 (1776)
>アプリケーションを終了するには [OK]をクリックしてください。
>アプリケーションをデバッグするには、[キャンセル]をクリックしてください。
でつ。

サイトの説明書きでは
>ここでは、クライアントPCに .NET Framework 1.0がインストールされている場合を例に説明します。
> .NET Framework 1.1では、一部のウィンドウ名などが異なります。
> .NET Framework 1.0と1.1が共存するマシンをご使用の場合、
>必ず1.0の［Microsoft .NET Framework Configuration］を使用してください。
だし、.NETって何なん。
メジャーバージョンアップ2.0を控えてる段階で。

JavaWebStartの例２

ttp://siisise.net/jnlp/GPen.jnlp

これは起動したこと無いので内容はわかりません。

Windows2000 + java 1.5.0 beta2 で動いたよ。
動作意外と速いじゃん。
内容はお絵かきツールみたいなやつだった。

漏れも .NETの実例が見たい

ttp://www.sellsbrothers.com/wahoo/

JavaWebStartの例３

ttp://sqs.cmr.sfc.keio.ac.jp/sqs-core/app/SourceEditor.jnlp
ttp://sqs.cmr.sfc.keio.ac.jp/sqs-core/app/MarkReader.jnlp
マークシート式調査票の設計・PDF原稿生成、OMR処理ができる。
ttp://sourceforge.jp/projects/sqs-xml/
から、ソースも取れる。

試してみた。

クライアントの性能のせいか（CPU:PentiumM1G, M:512MB）、
JavaWebStart、動作に不満はないんだが。

あのフォントはやっぱ、どうにかならんかね？
なんかびみょーににじんでいる気がする。

>>173

172は、実行環境非依存でPDF生成をするために、TrueTypeフォントを同梱しています。

オープン環境で使うリッチクライアント方式のアプリケーションなので、配布物に同梱
するフォントは再配布自由なものである必要があります。ということで、現状では
フリーの「さざなみフォント」を使っています。でも、残念ながら、さざなみフォント
の品質は、現状では、商用のフォントと比べると、あまり品質が高くないのです。

…っていうことかな？

>>173

それとも、

Java実行環境はTrueTypeフォントのレンダリングエンジンを自前で持っています。
ここにはバグがあり、SwingのGUI内の標準の文字が太字になってしまいます。
javaの実行時引数で、
-Dswing.plaf.metal.controlFont=Dialog-12
などと書くか、プログラムの先頭で、
System.setProperty("swing.plaf.metal.controlFont","Dialog-12");
などと書くことで対処できます。

…のことかな？

J2SE5で実行したら改善されてたりするのかな。

.NET良いのだけれど、せめてあとMacOSくらいには対応して欲すぃ。

Macはどうでもいいけど、Linuxだな。

リッチクライアントの命はサポート環境の広さだろ！

いや、クライアント環境は、いままでと同じように統一させることがある程度可能だから。
一般利用よりも業務向けのリッチクライアントが求められるわけで。
一般利用の場合は、変にリッチクライアント(=独自クライアント)だと使えないユーザーが増える。

普及率No1フラッシュ！

これは？
http://www.atmarkit.co.jp/fjava/products/flex/flex.html

サーバーとのやりとりをどうやるかだな。
というか、書いてる人が。

そのうちDIコンテナを持ったりAOPができたりするのか？

>>183
やっぱりSOAPかね？

SOAPというか、Webサービスだな。

>>185
でつね。ｽﾏｿ

Flex?そこまでしてブラウザでやらないとだめかなぁ。

最近はカウンタの回りが早くてよかよか＾＾
２ちゃんにも載ってるっぽいし有名人だね〜おれ！
と自慢している馬鹿サイト。
ttp://www.geocities.jp/el_seezer/
大学に復学しながらもだらだら休み続け、彼女に借金までしてる
アホ管理人サイト。
ttp://www.seoiba.com/
関西人の彼女を沖縄に誘致し、そして彼女の友達の下らんサイト。
ttp://rocks.exblog.jp/
此れが彼女の下らんサイト。
因みにコメント拒否。使うのはチャットのみ。

本人プログラマを目指しつつ学校さぼり中。
御小遣いは母親持ち。
母独り子独り。
大学では除籍決定。
嗚呼、情けない。

>いや、クライアント環境は、いままでと同じように統一させることがある程度可能だから。

出だしからおかしいな。
PC一色だった時代から携帯電話、デジタル機器に拡散してる時代に。

>一般利用よりも業務向けのリッチクライアントが求められるわけで。

業務一色が拡散してユビキタスみたく何でもかんでもイソターネットになってるだろうが。

>一般利用の場合は、変にリッチクライアント(=独自クライアント)だと使えないユーザーが増える。

リッチクライアントが炒らないんならこのスレ出てけ。

JavaWebStartはWindowsでサクサク動くし、
Linux、MACで動作するんなら、これで良いんじゃないかな。

>>189
そうですか。
JavaWebStartなら携帯電話・デジタル機器で動かせるのですか。
スマートクライアントなら携帯電話・デジタル機器で動かせるのですか。
Flexなら携帯電話・デジタル機器で動かせるのですか。

つうか日本語よめないやつか。
業務向けのリッチクライアントが求められてると書いてるじゃないか。

つうか日本語よめないやつか。
>業務向けのリッチクライアントが求められてると書いてるじゃないか。

業務向けだけじゃ駄目だから、
リッチクライアントの命はサポート環境の広さだろ！
で始まってるのに。

2行になると流れが読めないなんて可愛そうな椰子だ。

>JavaWebStartなら携帯電話・デジタル機器で動かせるのですか。
>スマートクライアントなら携帯電話・デジタル機器で動かせるのですか。
>Flexなら携帯電話・デジタル機器で動かせるのですか。

動かせるように激戦で整備されてるのを知らないようだ。
というかかなり動いてるだろ。

>>192
で、そうじゃない、といってるわけだが。
前の発言はすぐ忘れてしまうんですか。そうですか。

一般ユーザー向けの場合、利用頻度が高いか、処理手順が複雑なものでなければ、リッチクライアントは利用者の学習コスト高いから現時点では採用しない方がいいと。
業務向けの場合、利用頻度も高く処理手順が複雑になりがちなこともあって、リッチクライアントが求められるわけで。

>>193
少なくとも日本では、まだ使われてないというか使いものになってない。
動くだけでいいなら、なんでもありだね。

頭悪杉。論理的思考が無い椰子可愛そう。

>一般ユーザー向けの場合、利用頻度が高いか、処理手順が複雑なものでなければ、リッチクライアントは利用者の学習コスト高いから現時点では採用しない方がいいと。

リッチクライアントはWebブラウザアプリを包括するのに。
ダイアログも出来ればブラウザ内に収まることも可。

宣伝にふりまわされすぎ。数年後には言葉ごとあっさりなくなってそう。

>>195 >>197

>>196

日本語を正しく使えない同士がスレッドを荒らすのはやめてほしい。

>>196
それは違うと思うが、どうか？
JavaWebStartやらスマートクライアントの場合、ブラウザと行ったり来たりは難しいぞ。

>>197
言葉と実態がかけはなれてるし、HTMLクライアントとの単なる比較での言葉だから、言葉自体はなくなるだろう。
JWSもMSのも、単なるアプリケーション配布技術だからな。
ただし、言葉はなくなるが、普通に使われるようになるはず。

狂牛病のメカニズムはよくわかってない。、
「２０ヶ月」という数字に意味があるのかよくわかっていない。
そもそもアメリカの牛はきちんと年齢を管理されているわけでもない。

薬害のはじまりってのは、だいたいこんな風にして始まる。

>>200
頭悪すぎ。

行ったり来たりする必要ないだろ。

>>200
リッチクライアントおよびJavaWebStartはURL呼び出しで始まるんだから、
行ったり来たりは超簡単。

必要無いけど。

>>204
どうやってセッションを保持しますか？
なりすましを防御しますか？

>>203
そうすると、>>196が意味不明なのだが。

>>205
>>206

ちょっと議論ぽくなると頭に血が上って何も読めないくなるみたいだね。

>リッチクライアントはWebブラウザアプリを包括するのに。
>ダイアログも出来ればブラウザ内に収まることも可。

包括だ、包括。
行き来じゃない。

精神分裂馬鹿が自分の言ったことを捻じ曲げようと必死です。(ﾌﾟﾌﾟﾌﾟ

>>207
さらに意味がわからん。
日本語ヘタすぎ。

>>205は「行ったり来たりは超簡単」へのつっこみなのに。
包括ってなんだ？
JavaやVBで作ったアプリならHTMLクライアントと同じ機能を実現できるって事か？
それとも、JavaやらVBでHTML表示させるって話か？
> ダイアログも出来ればブラウザ内に・・・
ってどういうことだ？

http://dictionary.goo.ne.jp/search.php?MT=%CA%F1%B3%E7&kind=jn&mode=0&base=1&row=2

ほうかつ　はうくわつ 0 【包括】


（名）スル
ひっくるめてひとつにまとめること。
「全体を―して述べる」「関連諸法案を含む―案」

>>196
> リッチクライアントはWebブラウザアプリを包括するのに。


「包括」という意味を知らずに使ってしまった低学歴か、
本当に頭が混乱してる精神分裂か


どっち？ｗｗｗ

リッチクライアントに２種類ある。
i) Webブラウザの中のアプリ
ii) ダイアログアプリ

iはWebブラウザアプリでもある。
∴　Webブラウザアプリ ⊆　リッチクライアント

議論終了。

>>212
Webブラウザアプリってフラッシュとかアプレット？
リッチクライアントに含まれるんだから、当然HTMLオンリーは含まれないんだよね？

ダイアログアプリってなに？
ブラウザから別画面が起動するもの？
JavaWebStartとかスマートクライアントは、ブラウザとは独立して起動するよ？

もしかして、HTMLクライアントもリッチクライアントに含まれる、と主張したいの？

リッチクライアントっていうのは、HTMLクライアントをプアクライアントとしたときの、HTMLの制限を受けない一般アプリのことをいうんだよ。
わかってる？
ブラウザウィンドウ内で起動するもの、ブラウザから起動するものと、ブラウザとは独自に起動するものがあるけど。

>リッチクライアントっていうのは、HTMLクライアントをプアクライアントとしたときの、HTMLの制限を受けない一般アプリのことをいうんだよ。

ヴぁかだな。
フラッシュ入りブラウザアプリもリッチクライアントに入るんだ。
ちゃんと勉強しる！

現実的にはリッチクライアント＝オフィスの時代が来るだろうな。
一度は自分の市場だったわけだし、取り返しに来るだろ。

>>215
「ブラウザウィンドウ内で起動するもの」

>>1に書かれていないことからわかるように、
Javaはこのスレと関係ない。
ぇぶすたーととかほざいてる奴は、よく考えたほうが良い。

>>215
ま、それでもいいけど、そうすると>>196が「フラッシュ含むリッチクライアントで独自UIを構築すると学習コスト高い」の反論として、意味がわかりづらいんだけども。

>>218
とうとう気がふれて釣りに出たか。

>>220
釣も何もぜんぜん使われてないし・・・

>>221
釣り乙
過去レス嫁。

>「フラッシュ含むリッチクライアントで独自UIを構築すると学習コスト高い」

これはありえないでしょ。
HTMLが使い難いのでフラッシュ等でカバーするわけで。

>>220
サンプルがあれば使われてることになるの？
頭悪そうだよね。
はっきり言うけど、Javaなんか誰も使ってないって。
あんたが特殊な環境に居るだけだよ。

>>223
ありえないことはない。
HTMLは使いにくいが、少なくとも画面上の構成要素に関してはすでに利用方法を学習しているので、あらたなUI学習の手間が低い。
またHTMLの場合、ダブルクリックや右クリック、ドラッグなんかの、一般ユーザーがとまどう操作がないので、学習コストが低い。
ダブルクリック・右クリック・ドラッグは、開発者の想像以上に一般ユーザーはとまどうよ。
ネット接続の設定ができないようなユーザーはね。

使いやすさと学習コストは独立だから、使いやすいものが学習コストが低いとは限らない。
使いにくいものが学習コスト高いとも限らない。

>>224
あ、そう。
釣り乙。

っていうか、リッチクライアントの意味もわかってなかったやつに言われても説得力がないね。

長文乙

>>224
.NETは（ry

あと5年くらいはユーザーのスキルは低い状態だろうから、リッチクライアント採用するときには注意が必要、ってことで。
今の高校生くらいが社会人になって、自由にお金使えるようになるころから目に見えて変わってくると思われ。
やつらフリーターになるから自由に使える金が少ない、とかいうのは別の問題で。

>>226
俺は>>216以降だから。
ていうか、お前が釣だよな。
俺は真面目に書き込んでる。

はっきり言う、Javaは死滅の香りがする。
もう絶滅寸前じゃねーか。

>>225
論理的な思考が無いね。はじめからだけど。
ブラウザアプリはリッチクライアントに包括されてる、と言ってるだろ。
分かり部分をＧＵＩを消せば良いだけ。

むしろ、JavaとPDFの一騎打ちだな。
JavaWebStart、最強だし。

JavaはPdfより計算が速いから、Javaの勝ちだな。

で、ブラウザアプリってなに？
HTMLとの行ったり来たり、やりとりが必要ないんだよね？

>>233
でも、PDFよりインストールベースが少ないから、C#の勝ちだな。

>>231
自分で考えた定義を人に押し付けるのよりはマシだね。

>ま、それでもいいけど、そうすると>>196が「フラッシュ含むリッチクライアントで独自UIを構築すると学習コスト高い」の反論として、意味がわかりづらいんだけども。

自分で考えた定義ってこれだろ。
無理に「独自」を入れる低論理。

>>235
っていうかWindowはJavaで書かれている。
RinaxもJava。

>>212が論理的思考だというなら、こんな脳内定義を成長させる子どもだましの思考方法はほしくないなぁ。
間違った前提条件をこじつけて、自分に都合のいい言葉を定義することが論理的思考なんでしょ？

>>238
そのJavaはなんとHSPで書かれてるのですよ。

>>237
ま、勝手にわめいててください。
自分のレスに対するツッコミは無視して、自分論理ふりかざす人と遊ぶのも飽きてきた。

>>241
お前もう来なくて良いよ。

>>240
そのHSPはなんとCで書かれてるのですよ。
つまり、Javaの圧勝。

>>243
そしてそのCはなんと、ひまわりで書かれているのです。
びゅう太最強。

>>242
そうすると、今までの恥ずかしい発言をツッコム人がいなくなるからね。
よかったね。

>>244
そしてそのひまわりはなんと、びゅう太で書かれているのです。
Java最強。

なんか起源説がやたらと多いな
ニダが沸いたか？

要するにだな、Webアプリケーションをリッチに簡単に作りたいのです！
仕様変更する際に、無駄なコーディングやテスト等は行いたくない。
サクッと作れるやつ誰かおしえて。

>>248
MS Office2003でMicrosoftと心中汁！

>>248
それはリッチクライアントではないね。
ま、ASP.NETで。

>>250
そうなの？Webアプリもリッチクライアントになりうるんじゃないの?

>>251
だね。
でも言葉の定義の話はもうおなか一杯。

だからリッチクライアントマンセーで無問題。

>>251
HTMLアプリの対比としてリッチなんだから。

>>252
とりあえず、HTMLクライアントがリッチクライアントに含まれるといいはるやつだけはどうにかして欲しい。

せめてHTMLクライアントとファットクライアントの間にリッチクライアントがあることくらい知ってて欲しいね。

JavaWebStartにはブラウザを開いて(あるいは開いているブラウザに対して)
指定したURLを表示させる機能があるよ。
ttp://java.sun.com/j2se/1.5.0/docs/guide/javaws/jnlp/javax/jnlp/BasicService.html

おいらは、この機能を使って、署名つきJavaWebStart内で動的に生成したPDFを、
file:///c:/temp/hoge.pdfとかに書き込んでブラウザ経由で表示させたり、
JavaWebStart内からlocalhost上で起動したservlet engineと
Webブラウザの間でのhttp通信をさせたりしているよ。

HTMLクライアントとリッチクライアントとの区別に関する言い合いなんかはもう
どうでもいいから、こんなハックしてる奴がいる！とか、こんなハックをしたぜ！
っていうのを、見せてくれ。

>>257 それは２ちゃんねるの特性だから仕方がない。子供に「泣くな」というようなもので(ry

>254 ：デフォルトの名無しさん ：04/09/14 13:20:37
>HTMLアプリの対比としてリッチなんだから。

>255 ：デフォルトの名無しさん ：04/09/14 13:24:39
>とりあえず、HTMLクライアントがリッチクライアントに含まれるといいはるやつだけはどうにかして欲しい。

>256 ：デフォルトの名無しさん ：04/09/14 13:44:30
>せめてHTMLクライアントとファットクライアントの間にリッチクライアントがあることくらい知ってて欲しいね。

こりゃ間違いだ罠。
HTMLクライアントの進化がリッチクライアントであって、
間に位置するものじゃない。

実行環境がブラウザだけならHTMLクライアント、ブラウザとか他を含めればリッチクライアント。

リッチクライアントはHTTPでファイルのやり取りするが、
それがHTMLの場合もありえるし。

HTMLクライアントとリッチクライアントを別にする頭の悪いやつが居るんだね。

ttp://www.atmarkit.co.jp/fjava/column/andoh/andoh25.html

リッチクライアントの分類にFlashもあればBiz/Browserもある。
どころか、最も普及がFlashになってんじゃん。

もうええちゅうねんｗ

リッチクライアント技術でWebブラウザを配布することだってできるよ。
HTMLクライアントとリッチクライアントが、
どっちがどっちを起動するかとか、
どっからどこまでかどっちかを区別するなんて、全く無意味。

そのソフトがどのカテゴリに属するかじゃないくて、
そのソフトが何を実現したか、何を改善したか。これ重要。

>>263
そんな話はよそでやれ。
ここはリッチクライアントスレ。

>>260
> HTMLクライアントとリッチクライアントを別にする頭の悪いやつが居るんだね。

この場合のリッチクライアントは何？

とりあえず、どこ見てもリッチクライアントはHTMLクライアントに対する言葉ということになってるんだけど。
ttp://www.itmedia.co.jp/news/articles/0405/27/news059.html
ttp://www.atmarkit.co.jp/aig/04biz/richclient.html

HTMLクライアントのことをリッチクライアントと呼ぶこともあるなら、そういった記述のあるソース示してくれ。

なんで言葉の定義にこだわるかっていうと、通例としてリッチクライアントには含まれないものをリッチクライアントとして語られると、話が変になるから。
というか、変になってる。

そんな定義に興味はない

>>267
とりあえず、一般に使われていない使い方を、ここで使われるとスレッドがなりたたない。
話にならんだろ。

まぁ、ちゃんと勉強してないうちは言葉の定義の意義や大切さをしらなくてもしかたないか。
境界条件の定義には、あまり意味はないと思うけど。

>>269
おとなげないからやめれ

iモードJavaとJavaWebStartは同じようなもんでつか？

iモードJavaをそのままサーバに置けばJavaWebStartになるんなら楽なんだけど。

携帯端末で動かすなら、Nexawebがむしろいいのでは。
ソースのサイズもかなり小さいし、GUIのパフォーマンスもいい感じ。
JavaとXMLをしようするらしいが。。。
詳しく知っている人がいたら教えて。

匿名掲示板で間違った前提と異なるドメインを想定し、定義の議論と、その重要性を説く無意味さ。

>>271
ぜんぜん。
JNLPファイルの位置付けがADFと同じだけ。

だれも使ってない定義で話を進める無意味さ

プロプラ技術氏ね。

>>274
そうなんだ。
iモードJavaの説明サイト印刷してもショボイ画面だし、こんなん流行るんかな。
なんか、Ｓ∪∩のJavaに取り入れて貰えるんだっけか。

>>277
意味がわからん。
JWSは標準だが。

>>271
ふつうのアプリをJNLPと一緒にそのままサーバーに置けばJavaWebStartになる。
iアプリとはなんの関わりも無い。

了解>>278-279

結構Javaって理想の形ですね。
後、SwingがVCL並になってくれれば。

>>280
理想の形ではあるが、現実的ではない部分がある。

PC、PDA用のJavaWebStart開発したいのですが、
iアプリ開発セミナーみたいなのが役に立つんでしょうか？

>>282
なんで？
iアプリは関係ないって。
釣り？

最近のPDA用のJVMにはどんなのがあるんだっけ？
Sunは開発していないので有償のやつしかない？

iアプリはリッチクライアントとは言わんし。

JavaWebStart開発セミナーみたいなのありまつか？

Java真理教 自己啓発セミナーならあります

>>286
JavaWebStartの何が知りたいんだ？
つうか、なんでセミナーなんだろうか。
通常のGUIとそんなに変わらんから、JAVA PRESS35とかWEB+DB PRESS22とか読めば十分じゃない？

>>285
いやiアプリはリッチクライアントだが…？

>>289
ΩΩΩ＜なっ、なんだってー？

また、他に通じないリッチクライアント論がはびこります。

いや彼は普段iアプリ以下のプアな環境を使っているのだろう。
配慮してくれないと。

さ、じゃあ、俺が語ってやろうか。

※一昔前（かなり自身まんまんに）

■ファットクライアント／リッチクライアント
ローカルに実行体が置かれるタイプのクライアント。
代表的なのはVBクライアントアプリなど。
通信はSocketや、DB接続。

■シンクライアント
サーバに実行体が置かれるタイプ。
起動時にサーバとの同期が取られ、常に最新のクライアントが取得される。
代表的なのはブラウザ使用のWebアプリなど。
通信はHTTP。

■スマートクライアント
Microsoftが打ち出した、シンクライアントの１形態。
ブラウザ経由でサーバ上の実行体にアクセスすると、
ローカルのRuntime（.net framework）の資源を使用して、クライアントフォームを起動する。
シンクライアントでありながら、十分な性能を持つクライアントアプリを作成できるという。

※今（わけわかんないけど、多分こんな感じ）

■ファットクライアント
VBアプリ

■リッチクライアント
Webアプリでないシンクライアント
Flash, JavaWebStart, Applet, ActiveX, スマートクライアント

■スマートクライアント
昔と同じ。

>※一昔前（かなり自身まんまんに）

orz

>>294
どこさわってんだ、すけべ！

>>168
遅レスだが、マ板にコピペした奴がいてここにたどり着いたのでついでにレスしとく。
ここのもまたコピペのようだが。

> NET Framework のノータッチ デプロイメントに期待して、
> サンプル置いてるサイト実行したら、
「サイトの説明書き」の内容から検索した結果、サンプルとはこれのことだろう。
http://dotnetdemo.grapecity.com/demo/arnet/win_demo.htm

>IEExec.exe - 共通言語ランタイム デバッグ サービス
このエラーは、サンプル実行手順に書いてある通りにしたがわないで
このサイトを「信頼済みサイト」に設定しなかった場合に発生する。

書いてあるとおりに信頼済みサイトに設定すれば発生しない。
ちなみに俺は1.1しか入っていないので1.1の
Microsoft .NET Framework Configurationを使用した。
その結果問題なく動いた。（使ってはいないが少なくとも起動した）
エラーも起きずに起動するし互換性もちゃんとあるようだ。

リッチクライアントは決まった定義はないが共通するのは

ファットクライアント(VB, AWT/Swing)、シンクライアント(HTMLクライアント)
の問題点、配布と操作性の両方を解決したクライアント

これだけ。

>>293
配布技術がまざってるよ。
AWT/Swing/SWT via Java Web Startとか書けば良いじゃない。

リッチクライアントが浸透すると
もともとVB、AWT/Swingをやっていた技術者が
クライアントを作ることが多くなると思うんだけど
全部クライアントでやれば良いんじゃないとか言いそうで怖い。
さてさてどうやって説得しようかな。

>>297
リッチクライアントの話でJavaWebStartといったときには、当然AWTやSwingを使うことが前提だろ。
もちろんSWTでもいいけど。

>全部クライアントでやれば良いんじゃないとか言いそうで怖い。

あぁ、俺言いそうｗ。

そんな俺を説得してください。

>>299
用途で使い分ければいいですよ。
一朝一旦。
ファイヤーウォール越えや複数アーキテクチャの連携の予定がないんだったら、全部クライアントでも構わないと思う。

>>296
VBアプリが１台１台設定したりActiveXなんかのエラーが嫌われてウェブアプリマンセーになってきたのに、
ﾄﾞﾄﾈﾄノータッチ デプロイメントは作り方によってVBアプリと同様のエラーが出ると。
そりゃ意味無いな。

さらにﾄﾞﾄﾈﾄなんてライブラリが貧弱じゃん。
後発ﾏｲﾅｰ、サーバJavaを置き換えられず、Java Web Startに負けてるなんて、ﾍﾟｯ

ここで301に具体的に質問すると返事が返ってこないんだよなー。

せっかくのCASも >>301 のようなアホにかかるとかわいそうなことに。

>>302-303
と、具体的な反論出来ないため、煽り。

>>302
興味あるから具体的な質問してみてよ。

漏れはJavaWebStartでソフトを公開しているんだが、WindowsXP SP2以前は、
<object
codebase="http://java.sun.com/products/plugin/autodl/jinstall-1_4_2_05-windows-i586.cab#Version=1,4,2,0"
classid="clsid:5852F5ED-8BF4-11D4-A245-0080C6F74284" height="0" width="0">
<param name="app" VALUE="http://java.sun.com/products/javawebstart/apps/player.jnlp">
<param name="back" VALUE="true">
</object>
みたいにすると、Webブラウザ上でActiveX経由でJREをサイレントインストールして
JavaWebStartを起動できたんだけど、SP2以降は、ActiveXでの起動をするまでに、
いくつかの関門が作られるようになって、ユーザが明示的に許可しないとダメになった。
おかげで、馬鹿ユーザからの「起動できない」っていう苦情が増えたよ。仕方ないけどな。

>>306
単純なリンクにしたほうが簡単じゃない？

>>305
ﾄﾞﾄﾈﾄで足らないライブラリは具体的に何？

>>301
Java厨だからActiveXのときどんな感じだったから知らんが
設定すればいいんだから何が意味無いのかよくわからん。

JWSは、ActiveXのセキュリティ上ダメな部分を利用して
サイレントインストールを実現してただけなのに、
それをメリットと錯覚してるんでしょ。

>>308
本気で質問してるなら答えるよ。

>>308
俺に質問してどうするんだ。

>>312
何もわかってなさそうだから質問してみたんじゃない？
わかってると主張したいなら答えてみれば？
まぁ、わかってないんだろうけど。

>>311
本気だよ

>>314
なら、本気を態度かAAで示せよ。
ぜんぜん本気に見えない。
煽りたいだけに見える。

AAである時点で本気に見えないと思うが。

>>315
さっさと答えろよ。>>302が正解だったってことでもういいか？

>>315
ぁ-ぁ、逃げた。

ﾄﾞﾄﾈﾄに足りないのは処理ではオプソ系C/C++ライブラリ。
画面コントロールではDelphi/VCL。

オプソでは、
・OS（スパコンから組込みまでスケーラブルでセキュア機能のあるLinux、マイクロセカンドで動作するT-Kernel）、
・各種コンパイラ（実用言語から、研究系のオブジェクトベース言語まで無限）、
・マトラボのコピーなんかの解析〜プロット〜回路シミュレーションソフト（何百万で売られるソフトが無数）、
・gis製品からライブラリ、
とかベタなものでもこれだけが無料で落とせて書き換えてコンパイル出来る。
が、managed でないコードはﾄﾞﾄﾈﾄで動作しない。

売り物ActiveXなんてちゃちくてゴミどころか認識にも上らない。

>>317
AAすら貼れないへたれが何言ってる。

>>319
もっと普通にIMEとか答えようよ。
普段使ってて不便な部分を答えればいいんだよ。
いろいろあるでしょ。

>>319
画面コントロールは分かるが他はなんか激しくズレてるというか。

>>321
ゴメン、普段ITRON使ってて、
Windowsがマイクロセカンドで動かないから使えないんだ。
（実は組込みLinuxもミリセカンドでしか割り込みかからないから使えない）

Windows使うときは特殊なグラフィックライブラリ使うから、
C系とかDelphi/VCL絶対外せない。
超マイナーなライブラリもVCL探せば出てくる...

>>323
じゃぁ何で.NET使ってるのさ？？

あと、質問した人早くAA貼ってよ。

>>322
MATLAB会社にあるけど、自分のマシンにはインストールして貰えないから、
オプソのコピーソフト使って満足したんだい！

>>324
違うよ。
319がﾄﾞﾄﾈﾄに対する質問であって。


マシンにWindowsUPDATEﾄﾞﾄﾈﾄ入ってるし、
以前VS.NETインストールしたことあるけど、
ﾄﾞﾄﾈﾄ使ったこと無い。

なんか、CAD系の人がインストーラにﾄﾞﾄﾈﾄが要るとか要らないとか会話してた。
それ以外全く聞かないな。
つか、ソフト系の人でさえ知らない人も。。。

>>327
使ったことも無いのに文句言ってるの？？
謝罪AA貼ってほしいな。
ここ2ちゃんだからさ、AAが最重要なわけ。
わかる？

>>328
VS.NET入れたけどライブラリが無いから文句逝ってるんだYO！


　　　　　　　　　　　　　　　　　┌─┐
　　　　　　　　　　　　　　　　　｜も.｜
　　　　　　　　　　　　　　　　　｜う　|
　　　　　　　　　　　　　　　　　│来│
　　　　　　　　　　　　　　　　　│ね│
　　　　　　　　　　　　　　　　　│え .|
　　　　　　　　　　　　　　　　　│よ .|
　　　　　　ﾊﾞｶ　　　　ｺﾞﾙｧ　　│ !!.│
　　　　　　　　　　　　　　　　　└─┤　　　　ﾌﾟﾝﾌﾟﾝ
　　　　ヽ(`Д´)ﾉ　ヽ(`Д´)ﾉ　　(`Д´)ﾉ　　　 （　`Д）
　　　　|￣￣￣|─|￣￣￣|─|￣￣￣|─□（ ヽ┐U
〜 〜　￣◎￣　　.￣◎￣　　￣◎￣　　 ◎−>┘◎

>>329
入れたけど使ってないんじゃ意味無いじゃん。
使えよ。

>>329
今までのライブラリ使えるのに文句逝ってるんだNA！

>>330
正直、組込みじゃ使えんし、
Windows製品でも使わない方が実行環境狭めないし安定だし。。。

>>332
使わないなら別に文句ないじゃん。
何で文句言ってるの？？

>>333
Winがマネージ度のみになるのは良いけど、
C/C++ライブラリとVCLが動作せんのならメンドー。

プラットフォーム変えてやるか、
みたいな気分。

>>334
何言ってるの？？
ウインドウズでVCL動くじゃん。
ライブラリも昔より良くなってるよ。
2003ですごく良くなったじゃん。

>>334
動作するだろ。

早く謝罪AA貼ってほしいな。

>>335-336

2003はサクサク動く。

問題は、ロングホーンの次のOSくらいの話。

正直すまん買ったて奴でいいよ。

ﾄﾞﾄﾈﾄに足りないライブラリ質問は出したから、
次ﾄﾞﾄﾈﾄ側が回答しる！

>>338
まだ骨格すら決まってないOSについて妄想して文句言ってるの？？
それどういうこと？？
ぜんぜんわかんないんだけど？？？？

>>340
回答したじゃん。
一番困ってるのはIMEの便利なクラスが無いこと。

お前らそれ以上はスレ違いだから続きはこっちで↓
http://etc3.2ch.net/test/read.cgi/entrance/1096118923/

Java Web StartでJDBC使う場合、JDBCドライバのインストール＆設定なんかで問題おきまつか？

>>344
他のライブラリといっしょ。特別な問題は起きない。

Java Web Start によってAppletは死滅しまつか？

>>346
いまあえてAppletを使っている人がAppletを使わなくはならないだろうし、これ以上は死滅しないとおもいますでつ。

>>347
今まだ使ってない人は、Appletを積極的に使うのは良くないということですか？
Java Web Startに逝け、と。

>>348
Webページに埋め込みたいならApplet。
Webページに埋め込む必要がないならJWS。

Flashリモーティングの情報が少ないな
OpenAMFの情報とかってどっかにありますか？

>>350
OpenAMFは俺も今、格闘中
ほんと情報少ないよね

純正使いたい・・・ orz

Flash敷居高そうだ。ぜんぜん使えない。

http://dotnetdemo.grapecity.com/demo/arnet/win_demo.htm
ここのノータッチデプロイメントの実相例はよくできてる

>>351
Seasar (2じゃなくて1の方)では案外ラクチンにAMF使えたよ。

>>354
openAMFとs1(2)openAMFって中身同じじゃなかったっけ？

openＡＭＦも基本的に楽なんだけど、EJＢを使う場合、かなり癖があ
るかんじで困ってる。

純正のremotingだと、先ずEJBHomeオブジェクトを取得して、create
でEJBオブジェクトを生成するといった通常の手順でＯＫなんだけど、
OpenAMFだとその方法ではNGで、getServiceするとEJBそのものが
帰ってくるんで、EJBHomeのfinder系のメソッドを使いたいときに非常
に不便を感じてる。
しかも、EJBにEJBHomeを返すメソッドを実装して、そのメソッドをflash
から呼び出すとIOExceptionが発生するし、もう分けわかめ・・・

■remoting
var service = con.getService("HogeBean",this);

とするとserviceにはHogeBeanHome(EJBHome)が代入される。

■openamf
var service = con.getService("HogeBean",this);

とするとserviceにはHogeBean(EJB)が代入される。

OpenAMFのgetewayサーブレットつかってますが、
いまだにopenamf-config.xmlファイルにさわってない。
ここの設定でいったい何をするんでしょうか

SWFからFLASHリモーティングつかってサービスを呼ぶ場合、
そのサービスがSWFと同じサーバー内にあれば動きますが、
SWFが別サーバーにおいてあっても動かしたい場合、
Webサービスとしての実装しかないのでしょうか？

>>357
たぶん crossdomain.xml が必要

NexaWebとかはどうよ。

JDNC情報ｷﾎﾞﾝﾇ

どの程度仕様策定が進んでいるのかとか、
Mustangに入るか入らないかとか、
どこぞでNightyBuildが見れるとか。

リッチクライアントってAvalonが出るまでのつなぎのような・・・

M$Nニュースの見解は >>362 の逆かも

ttp://www.mainichi-msn.co.jp/it/coverstory/news/20041130org00m300066000c.html
>今後の課題は、技術好きなユーザー層ではなく、
>必要に迫られて使っているユーザーに
>どうやってリナックスを知ってもらうかだという。
>同氏は、大きな転機は2、3年後とみられる次期ウィンドウズ「ロングホーン」の
>リリースの時に訪れると考えている。
>ウィンドウズからロングホーンへのバージョンアップは、
>リナックス移行と同じぐらいの難易度になるとの予測からだ。

マルチうぜぇ

すいません。スレ違いかもしれませんが教えてください。

windowsで動作するアプリを作成してみたい（勉強したい）のですが、
例えば、VBで作成するとだとランタイムが利用するマシンに必要になるとおもいます。
こういったランタイムなどの配布なしで動作するアプリを作るには
どのような技術を勉強すればよいのでしょうか？？

>>365
HSP

自己レス

開発元本家に行けばよいだけの話でした。
https://jdnc.dev.java.net/
逝ってきます

sage

Macromedia Flexが虫の息です。
誰か死に水を取ってください。

まあ、畑が違うからな。
どんなに頑張っても無理だべ。

開発環境もこれから順次整ってくるだろうし
ひとしきり落ち着いてから価値を見出そうと思ってるんだけどなぁ。

2004proのフォームベース開発は
あまりにも流行ってなくて見切りつけたけどｗ

っていうかさぁ、この分野、供給が需要を上回ってない？

UIなんてただでさえ複雑な細かい制御が増えるわけだし、
テストしやすさ、リファクターのしやすさがどれほどのものかというのが重要な基準。

JavaWebStartでフルJavaですよ

flex高すぎ
あれはflashで開発する力がない開発側の都合で導入するものだろ？
少なくとも、システムを発注する顧客にとっては、flashでUI作ってくれ
たほうがよいわけで、flexでなければならん理由なんてないだろう。
広がらない理由は、高すぎること(値段に見合った導入メリットがない)
これに尽きるんじゃないの？

XHTML+RCC+SVGが5年後の未来ですが何か？

XULもいいけどね標準になりえないし。FlashやJavaWebStartは組みやすいけど
所詮プラグインのランタイムが必要。主要なブラウザ内部に組み込まれること
が重要。

５年後はワカランが３年後なら、オレはJSFだと思うよ、JDNCとケコーンした後のな。

>>374
Flexはたしかに高いね。
よく分からんがFlexだと動的にSWFが生成できるのが利点
みたいだけど、そういうニーズがどのくらいあるのか疑問。
あと動作が重くなるのは商用サイトではマイナスだと思う。
理想は高いが現実が追いついてないというか現実を無視した感がある。

とりあえずlszloに期待。
まあ、動作は重いけどな…(´･ω･`)

＞＞2004proのフォームベース開発は
＞＞あまりにも流行ってなくて見切りつけたけどｗ
なぜはやらないんだろうか

flexって、swfでjspみたいな事やってみたかったの、って
だけな気がするんだよなあ。
MXの重さ考えると、やろうと思えばちょっとした修正は
秀丸でだって出来ちゃいそうなのは魅力なんだけど
ほんと、高い！

laszloをjbossに突っ込んでサンプル動かしてみたけど重すぎる。
こりゃ普通にflashでUI作ったほうがいいな。

>380

買うのはクライアントだ。
開発版は無料だし。

お客さんに「買わせる」のは開発者でしょう？

うちのクライアントはちょいとプレゼンしたらすぐ買ったけどな

でも、まだ枯れてるとはいえないものを
提案するには、やっぱり高い・・・・。

その分こんだけ工数減りますよーとか
自信をもっていえるようになれればねえ。

むしろ工数が増えそうな悪寒

Flex（笑）

HTMLでWebアプリだったら、開き直れる分（できないものはできないと）、
安く上がったりして。

結局データ入出力に関しては同じことする必要があるから、大して変わらないかと。

>>388
結構それって重要だよな。

今年はEclipse RCPが来そうな予感。

flashって簡単にswfからflaに起こせて
actionscript丸見えだから怖いんだよなあ

Javaだけの利用を前提条件とすると、
リッチクライアントは必然的にAppletしかない？
最近のアプレットって、ビジネスアプリへの適用に耐えうる？

java web start使って配布という手もある

>>391
それって、Eclipseのプラグイン的なもんだから開発言語はやっぱJava?

WindowsにJava5が標準添付だったら状況はかわるね。

Flash使ったら機器とPCとデータやり取りしやすい、とかある？

Java Web Start = Swingの実行環境
Eclipse RCP = JWTの実行環境

であってまつか？

JavaWebStartでAWTのプログラムでもSWTのプログラムでも配布することはできるわけだが。

あ、根本的な間違いしてるね。
JavaWebStartは実行環境というより、配布・実行形式だから。

thx! >>399 >>400
Javaって難しいね。

・・・そこはJavaが難しいところではないと思うが。

>393

Java + Flash = Flexでどうでしょう

Flexはコストかかるし、重いじゃん。
漏れ的にはまだFlash+Javaでいいと思う。
まあ、データグリッドの表示が遅すぎるのが難点だが。

Flexはホントに大コケだったね。
Macromediaの経営に影響がなきゃいいんだけど…。

過去形ですかっΣΣ(ﾟдﾟlll)

高杉だし。

Flexに注目しようとしてたのに、本当かい？

ajax
tp://antipop.zapto.org/docs/translations/ajax.html

これを取り込んだナイスなプレゼンテーション層の
フレームワークが出ればflexは要らん要らん。

高すぎ？
別に個人で買うわけでもないし

>>409
それは何時出来まつか？
待ってまつ。

>>410
前にもこんな話が出たけど、買うのはお客さんなんですよ。
そのお金見積りに入れなきゃなんないのよ。
お客さんに「個人で買うわけじゃないんだから
これくらいいいですよね？」なんていえませんよ。

>>411
ひがたんがやる気、なのかな？
tp://d.hatena.ne.jp/higayasuo/20050223

ajax関連もひとつ
tp://allnight.cocolog-nifty.com/usability/2005/02/ajax.html

もふたつ
JSON-RPC(AjaxのJava実装)ちょっといじりました記事
tp://d.hatena.ne.jp/masakas/20050224

>>412
>そのお金見積りに入れなきゃなんないのよ。
で、イクラ？

Webブラウザアプリとダイアログアプリと一つのコードで作るには、
何が良いでつか？

普通にJava

ブラウザのコントロールをリッチにしてくれればいいのに

そうするとまたMS暴走するからダメ

とか言いつつ、FireFoxのようなXULプラットフォームで業務アプリに使えるレベルの
リッチクライアントが実現できたらうれしいのだが。

「Flash Mx 2004 Pro + Webサービス」ってどう？

>>417
そうそう、自分もWindowsマシンは肯定するが、
M$のリッチクライアントは否定する。

>>418
悪くないけど、許されるなら「Flash Mx 2004 Pro + Flash Remoting」を選ぶべき。
XML WebサービスとFlash Remotingを比べるとパフォーマンスに差がありすぎる。

OpenAMF（だっけ？）は？

OpenAMF面白そう！
商用ソフトで固めなくてもいいとこは試してみたらいいかもね。

ドラえもんの声優決まる

　テレビ朝日は８日、２６年ぶりに声優陣を一新すると発表した同局系の人気アニメ「ドラえもん」で、オーディションによって声優陣が決まったことを明らかにした。
　それによると、ドラえもんはテレビ東京系アニメ「わがままフェアリーミルモでポン！」のミルモ役で知られる小桜エツ子さん、のび太役には日本テレビ系アニメ「犬夜叉」の珊瑚役で知られる桑島法子さんが演じるという。
　新声優陣は、テレビ朝日のホームページ（ｈｔｔｐ：／／ｗｗｗ．ｔｖ−ａｓａｈｉ．ｃｏ．ｊｐ／ｄｏｒａｅｍｏｎ／）でも発表している。
　　 - 3月8日16時50分更新

http://headlines.yahoo.co.jp/hl?a=20050308-00000030-ykf-ent

>>420
なるほど、サーバ側はRemotingの方がパフォーマンスがいいんですね。
でも価格と汎用性を考えると、Webサービスを選択したくなっちゃうんですよね。
サーバ側をWebサービス（SOAP）にしておけば、
リッチクライアントをFlashからJavaWebServiceやスマートクライアントへ変更するのも容易ですしね。

>>424
そこら辺の利点は魅力的ですね。
ただ、「来るかどうか分からない未来のために汎用性を確保しておく」というアプローチが
本当に必要かどうかは熟慮しておく必要があると思います。

RemotingとWebサービスは排他ではないので、共存も可能です。
前述と矛盾するようですが、そういう意味で汎用性も確保できます。
結局はコストの問題に行き着くんですけどね。

まあ、用件定義次第ってことになるんですかね。

>>417
業務アプリに使えるレベルっていうのがどの程度をさしているのか
分からないんだけど、MozillaとかFireFoxの完成度を見ると十分な
パフォーマンスを持ってるように思える。
IEやOperaで使えないので業務では採用しにくいけどね。

うちの会社はデフォルトのブラウザがNetscapeなので
イントラアプリにXUL＋PHPを使ってみようかと思ってます。

http://www.xamlon.com/software/xamlonpro/flash/mapexplanation.aspx

Ajaxはどうなの？といいたげだな
Ajaxなら実際無問題だが
それに食いつかないプログラマが多いのも事実

正直 JavaScript のブラウザごとの仕様に振り回されるのは
いやだしなぁ...

>>429
そこまで作りこむことしてないくせによく言うよ

DOM Level1の機能だけ使っていくだけでブラウザ非依存でそれなりのものできるし

さて…
Microsoft VS Adode + Macromedia
の戦いになるわけだが…

ならねーよｗ

Frontpage と METRO、C# を武器にして戦うの見てみたい

これからは、Laszloじゃない？
http://laszlo.no-ip.org/index.php?Laszlo%20Japan
http://www.atmarkit.co.jp/fwcr/rensai/laszlo01/01.html

ｲﾏｻﾗAdodeにﾜﾗﾀ

Laszloいいな。ちょっと検討してみよう

LaszloでJavaRPC使って日本語文字列をJavaBean（POJOでも）にセットしたいんだけど
文字化けする・・・。

なんだかんだ言って機能的にはAppletが最強クラスなんだよな。

ブラウザを飛び越えて進化するリッチクライアント@IT
http://www.atmarkit.co.jp/fwcr/special/richclient01/02.html

CS型から移行することを考えれば、クライアントにアプリを
インストールするスタンドアロン型は考えられない選択枝だ。

ブラウザ型の中でユーザ普及度が高いものを考慮すれば、
FlashかAjaxのどちらかだろう。

しかし、ブラウザだけで実現するAjaxは表現力が弱いような
気がする。開発も難しいみたいだね。

>>440
どうせはいってるだろうOfficeは選択肢としてはありだと思うよ。
まあ、適材適所だけど。

flexやらされてるけどしんどいね
鯖屋の方が悲鳴上げてるけど

>>442
flexって、IDEがあるからVBのようにポトペタで簡単に作れそうに見えるんだけど、
具体的にどの辺がしんどいの？

あーあのIDEはちょっと規模大きくなるとmxml（flexのページ記述言語およびファイル）
一枚読み込んで表示するまで５分とかかかるから意味無いよｗ
細かい画面のレイアウト詰める程度に役に立ってるけど…総合的な開発の軸にはどう頑張ってもﾃﾞｷﾈ

画面遷移重とくViewStackってタグがIDE上でスクロールできないケースがあって
結局ソース書く技術ないデザイン畑の奴はレイアウト作業から外され気味。
レイアウト作業で泣くのは俺じゃないからいいけど　いや良くないな一応あれでも仲間だぞこの野郎

実はしんどいのはその辺じゃなくてパフォーマンス制御
最初にサブ画面まで読み込ませると平気で60000msとか掛かるし
最初に読ませないと画面遷移の度に3000msとかかかるし
ブラウザのメモリ使用量は平気で追加で200MByteとか読んでるし
削るにはキャッシュ捨てなきゃいけないからさらに画面遷移重くなるし
ユーザの苦情が目に見える

むしろ俺より鯖管が悲鳴上げてますね
ｱﾌﾟﾘ系の鯖設定には慣れてる人のはずなんだけど、どーやっても異常にメモリ食うとかで困ってらっしゃる。
あんまBtoC提供に向いてるシステムじゃなかったのかもなあ
上からの鶴の一声で決定した作業とはいえ、正直ﾏｸﾛﾒﾃﾞｨｱ営業の口車を恨んでまつよ
サービス開始直後に破綻しなけりゃいいけど

ていうかとっととIDE更新して欲しいよ
Ecripceﾍﾞｰｽにするならするで今よかマシならなんでもいい

長文の愚痴失礼

現場の声トンクス。参考になりますた。

一時期、IBMがalphaWorksでeclipseベースのflex環境、公開してたけど
すぐひっこめちゃったね。

>>444

> あーあのIDEはちょっと規模大きくなるとmxml（flexのページ記述言語およびファイル）
> 一枚読み込んで表示するまで５分とかかかるから意味無いよｗ

そんなんじゃ、IDE役に立たないねぇ。

> 最初に読ませないと画面遷移の度に3000msとかかかるし

従来のHTMLの画面遷移の方が速いんじゃ･･･。
それって、画面切替時に次の画面データをサーバから受信して
Flashでレンダリングするから遅くなるってことかな？

> むしろ俺より鯖管が悲鳴上げてますね
> ｱﾌﾟﾘ系の鯖設定には慣れてる人のはずなんだけど、どーやっても異常にメモリ食うとかで困ってらっしゃる。

OpenLaszlo の SOLO デプロイメントモードのような逃げ道？があれば
いいと思うけど flex はサーバも束縛されちゃうんだよね？　大変そう。
まあ無理して(笑)頑張って下さいね。

>>446
IBMはOpenLaszlo（Laszlo Systems社）のパートナーみたい。
ということでそれと関係ありそうだね。

そういやfaces for OpenLaszloもIBMが出してたな。

>>441
Office、Flash、ブラウザはよく普及しているからよい、
と思ったが逆にまずいような気がしてきた。

これらのソフトは新しいバージョンが発生するとユーザ
が自ら更新してしまう。
システムの動作検証してないからダメともいえないし。

それならむしろユーザが勝手にアップデートしないで
あろうCurlとかの方が安心感がある。

Officeってプログラムの配信はどうやるのかな？
Web上に配置したExcelファイルを開かせるというのなら分かるのだが・・・。

プログラムを修正したら直ちにすべてのユーザが必ず最新のプログラムを
使わなければならない。それが簡単にできるのあれば採用したいが
そうでなければ今までのCS型システムと変わりない。

最近３連続で規模のデカイ仕事してるんだけど
どこもクライアントはSwingだった。
そんで３つともオリジナルのリッチクライアント用フレームワーク作ってた。
あ、サーバー側もオリジナルだな。（何かに付け足すダケだが・・

毎回用語とか設計方針が違うからめんどくさいんだよな。

OfficeなんてWindows限定だからｲﾗﾈ
JavaAppletは環境によっては動かなかったりしそうでﾄﾗﾌﾞﾙが怖い。
Curlはよさそうだけど、ﾏｲﾅｰで技術資料とか少なそうだし。ﾀﾀﾞで使えればうれしいんだけど。
現状ではFlashが一番無難そうに思える。俺の個人的な好みもあるけど。

Eclipse RCP
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20050920/221409/

今流行りのAJAXってどうなんだろう？
ブラウザによって動いたり動かなかったりの
問題があるらしいんだけど、プラグインが不要だし動作が軽快なんだよね。
IDEが出てくれば大抵のWebアプリはAJAXになりそうな勢いを感じる。

>>454
> IDEが出てくれば

Visual Studio 2005 + Atlas

>>454
個人的には、Flashと住み分けて行くと考えてる。

>>455
AtlasはIE依存になりそうで何か嫌だなぁ。

>>456
Flashお得意の見た目の派手さ、プラス使い勝手のよいものならいけるかなぁ。
個人的にはOpenLaszloがよさげだから期待したい。

Flashベースのリッチクライアントといえば、Open Laszloと
本家Macromedia Flexだが、Open Laszloは無料でFlexの
方は数百万円。
これじゃあOpen Laszloが圧勝だよね。
となると本家Macromedia社としては面白くないから次の
Flashは仕様を変えてくるのではないだろうか？

OpenLaszloのライバルはflexよりもAjaxだと思ふ。
そのどちらにも長所・短所があるから、
ケースバイケースで使い分ければいいんじゃないかな。
なんで両方マスターしておきたいと思ふ今日この頃。

>>458
無料か数百万かっていうだけで勝負なんかつかないよ。
学生さんにはわからんだろうけど。

>>458
460に補足。
オープンソースはよほどメジャーな存在にならない限り
自力で保守しなければならない。
保守契約を結ぶのが困難な場合、企業側としては躊躇
する。
また、技術者が少なければ開発委託するにも要因確保
できなかったり、単価が高くなったりしてやはり躊躇する。
ちゃんとした企業が提供する有料ソフトであれば安心し
て導入できるし、上層部にも納得してもらえる。

>>458
もう１つの仕様を変えるって話もどうかと思う。
そんなことしたら世界中で広告やアニメに使用されて
いる既存のFlashコンテンツが表示しなくなることを意味
してるわけだから、それはありえないだろう。

>>461
それは昔の文脈。

今はどこでもオプソマンセーの空気。
リッチクライアントなんて注目分野はオプソ側に人集まりまくり。

>>461
>また、技術者が少なければ開発委託するにも要因確保
>できなかったり、単価が高くなったりしてやはり躊躇する。
flexなんて所詮マイナーな製品だから、おそらくできる人間は少ないでしょう。
だから単価云々の一般論は関係ないよ。

>>460

>無料か数百万かっていうだけで勝負なんかつかないよ。

１ソフト数百万のオーダーまで価格が下落したから、
エンジンが無料か数百万かっていうだけで勝負付くだろうね。

ボラクルだってこれからはﾔﾊﾞｽ。

Flexやってますが技術者おらんとですよ
教育コストばかりかさむ
ﾑｶついたんで趣味鯖でLaszlo起用

↓にリッチクライアント技術の比較表あり
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20050926/221680/

Biz/Browserっていつのまにかバージョンアップしてたです。

v4.1(XE)
http://www.axissoft.co.jp/biz/xe/

評価版使ってみたけどなかなか良さげ。
今まで出来なかった部分がわりと簡単に実現できそう。
次の開発で使おうと画策中。

ただこの評価版、Designerから直接実行するぶんには問題ないけど
http経由で画面開こうとするとライセンスがないって怒られる。
なんでlocalhostに対するライセンスが要るんだ？評価版なのに…

>>468
ライセンス料はいくらなの？

http://www.axissoft.co.jp/biz/bizbd/bbprice.html

>>470
サンクス。この金額なら大企業にとってタダみたいなもんか。
これって社内向けシステムにはよさそうだけど、BtoC サービスには向いてなさそうだね。

セル操作（Excel的な操作画面）を作るのに適してるのはどれですかね？

>>472
内輪で使うだけならActiveXが一番簡単だしパフォーマスも良いと思う。
ActiveXがダメならAjaxかな。ただし実装が大変なのは言うまでもない。

Biz Browserに興味もったんだけど1URLつーライセンスがよくわらりません、後、想定ユーザ数全員分ライセンス買わないといけないのこれ。たっかいね

>>474
http経由でCRSファイルをロードする際、そのサーバに対するライセンスファイルがないとエラーになる。
事前にライセンスファイルを配布設定しておくか、またはサーバ上に仕掛けておいて
トップページのロード時に専用メソッドでダウンロードする必要がある。
これがURLライセンス。

ユーザライセンスのほうは、Biz/Browserでアプリを使う台数ぶん必要。

つFlashPlayerControl .NET
http://blog.thebadtiming.com/archives/940

FLASHって、マルチスレッドできるのか？

このスレまだ生きてるね。

Visual Studio 2005 Tools for Office がそれっぽいかなと
思ったけどちょっとややこしい。

Bizはサポートが感じ悪い。
さっさと、さよならしたい。

あげたい

■IME2003にタダで乗り換える方法

WindowsXPやOfficeXPに付属しているIME2002は色々と不便な所が多く、
(例えば、IMEツールバーをタスクトレイに入れることが出来ないなど)
IME2000をインストールして使うかIME2003にバージョンアップすることを
お勧めします。OneNote体験版でME2003のみをインストールできます。
OneNote体験版の期限が過ぎてもIME2003を使い続けられます。
OneNoteをアンインストールしちゃうとIME2003が消えてしまうので注意。
ダウンロードは以下のURLから。

ttp://www.microsoft.com/japan/office/onenote/prodinfo/trialoffer.mspx

メールアドレスなどの入力を要求されますが、「[email protected]」のように
適当なものを入力して送信すればダウンロードできます。
プロダクトキーが書かれたページも表示されます。
プロダクトキーはインストール時に必要なので保存しておきましょう。

ttp://www.microsoft.com/office/onenote/prodinfo/trial.mspx
ここからLanguageをJapaneseにしてダウンロードしてもOK。
でもメールアドレスは生きているものが求められます。
IME2003が入っているOneNote.exeは152MBです。落としたのが90MBくらい
のOneNote.exeの場合、そのOneNote体験版は日本語版ではありません。

インストールの時はカスタムインストールを選択し、「Office 共有機能」
→「入力システムの拡張」のみにチェックを入れ他は全部外せば
IME2003のみをインストールできます。(96MBくらい)
インストーラーのバグなのかどこかのドライブのルートディレクトリに
「MSOCache」というフォルダが作成され削除されずに残っているので、
インストールが終わったら手動で削除してください。

IME2003最新語辞書更新
ttp://office.microsoft.com/ja-jp/FX010937461041.aspx