アカウント名:
パスワード:
などなど。とにかくもうちょっと説明してください。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
Ajaxってどうですか？ (スコア:2, 参考になる)
予想が外れた時は高い代価を支払う事になる気がします。
具体的には、その"サイト"内での動作は高速でしょうが、
関係ないWebページ間をグローバルにジャンプを繰り返すような動作に弱いと思います。
そして、その様な多様性こそWebコンテンツの醍醐味だと思うのですが如何でしょうか?
#個人的趣味としてあんまり好みじゃありません。
#「small is beautiful」の美学から外れているっていうか、 この様な発想が比較的容易に実現できるのは、
#母体のHTTPが「small is beautiful」の美学に基いているからだと思うんですが、
#こんな風にしてしまうと次世代の発展が難しくなるのでは?
Re:Ajaxってどうですか？ (スコア:1)
などなど。とにかくもうちょっと説明してください。
Re:Ajaxってどうですか？ (スコア:1)
>「関係ないWebページ間をグローバルにジャンプ」の意味がよくわからない
他のサーバの、というか、別の作者のページと言う事です。
つまりAjaxの作者が感知しないページ。
>「予想制御」という言葉も聞きなれないが、予測制御?だとして、Ajaxのどの辺を指して言及しているのだろうか。その「高い代価」とは。その後の具体的記述との関係がわからない
この場合、ユーザーの要求を先読みしてデータを取得すると言う事です。
予想が外れると、無用なネットトラフィックとマシンパワーを消費します。
>コンテンツの多様性と、「グローバルジャンプ」の関係は?
異なる作者が製作したコンテンツが有機的に結びつく事により、
単一の作者の製作したコンテンツに比して、多様性が飛躍的に向上する物だと思います。
>どうして「次世代の発展」が難しくなるの?HTMLでの静的コンテンツ及びそのハイパーリンクという構造では満足できないから、リッチクライアント技術がこうやって勃興しているのではないのか
この技術を基礎にした新しい技術を開拓するためには、
覚えなきゃいけない事がいっぱい有りそうだって事です。
すみません、この辺りは多分に個人的意見が入ってます。
>少なくとも現行のAjaxアプリケーションのほとんどはサイト内コンテンツの高速提供を目指している
純粋に技術的な観点から言うと、単一の作者によるその様な動作のコンテンツは、
更新情報の取得を除けば、ローカルで動かすべき物だと思うのです。
Re:Ajaxってどうですか？ (スコア:1)
>少なくとも現行のAjaxアプリケーションのほとんどはサイト内コンテンツの高速提供を目指している
実際そういった目的にはスマートなアプローチであり、興味深い技術だと思います。
ただ、純粋に技術的な観点から言うと、単一の作者によるその様な動作のコンテンツは、
更新情報の取得を除けば、ローカルで動かすべき物だと思うのです。
もちろん、ユーザーの心理的障壁の低さや、ローカルのマシンパワーの問題など、
こういた方式のメリットはあると思います。
ですが、それらは多分に社会的要因に起因するメリットであり、この技術は時代のあだ花的物 ではないかと思うのです。
Re:Ajaxってどうですか？ (スコア:0)
サーバーの能力が上がった時にサーバーサイドに振れ、ネットワークやクライアントの能力が上がった時にクライアントに振れます。
処理をサーバー/クライアントでやる*べき*ということはありません。その時のコンピューティング環境によって最適解が違うだけです。
で、今までのWebはサーバーサイドで処理をするムーブメントのひとつだったわけです。
そして近年になり、ネットワーク帯域とPC能力が劇的に拡大し、処理の比重はクライアントサイドに移って
Re:Ajaxってどうですか？ (スコア:0)
> コンピューティング環境によって最適解が違うだけです。
その通りだと思います。
ただ、Ajax に対しては、確かにリッチクライアントではありますが、
XMLHttpRequest によって、サーバサイドに処理を依頼するというアプローチ
が、他のリッチクライアントな技術と少し異なる様に思います。
そのため、単純にクライアントサイ
Re:Ajaxってどうですか？ (スコア:1)
Webアプリを使ったり作ったりしてて、つくづく思うんですが、
俺たちゃ、べつにwebアプリが欲しいわけじゃないんですよ。
欲しいのはアプリ。
たまたまWebを使ってしまってる(時として使わざるを得ない)だけ。
で、そう考えると、そもそもページジャンプなんて、アウトオブ眼中でいいんですよ。
アプリなんだからさ。
そのやりたい事柄の中にページジャンプが入ることなんて、(滅多に)無いよね？
俺としては、「アプリ」にとってはページ遷移という概念すら不要だと思っています。
欲しいのは画面の書き換えであって遷移じゃないんだよな。
＃アプリから見れば画面遷移なんて概念は、GUIアプリでいうEventを(MFCすら使わずに)生で扱わされてるのと
＃同じレベルの原始的さだと思うぞ。
＃だからWebDesktopServerなんて概念も考えてみたし(^^;、EchoWebFrameworkみたいなのに期待するし、
＃JSFに未だに画面遷移という概念が有るのに不安を感じてるし。
＃てゆーかJSFってStrutsと同じ人が仕切ってんだってな [itmedia.co.jp]。大丈夫かよ？
HTTPとかHTMLはたしかにシンプルですが、
適切な用途が(このトピックに適合した話題としては)狭すぎるんです。
HTMLは静的なページとしてはそこそこイケてるメディアですが、
動的なページつまりwebアプリとしては、
通信形態もUI形態も、最悪の最悪。昔のパソコン通信以下かも。
だから、全然違うやり方をしたくなるのは、当然です。
で、どっちかってーとAjaxって、伝統的Webアプリの延長というより、
最近の流行り言葉でいう「リッチクライアント」を
JavaScriptで実装したものだと捉えたほうがいいと思います。
JSのコーディング自体は、さぞかしゴチャゴチャになりやすいでしょうけど、
そういうのはまあ、最初からライブラリを組んでおくってゆーことで、どーでしょ？
つまり、HTML(JS含む)レベルでの綺麗さなんてものは、捨てましょ、ってことです(^^;。
あんなもんはアセンブリ言語や16進ダンプと同じだと思ってさ。
単にWebアプリの画面部分を送受信するための手段でしかないから、
ラッパーが吐き出すHumanReadability低いコードでも、いいじゃんと思っています。
HTMLレベルのシンプルさは捨てますが、
換わりに、もう１つ上位のレベルでのシンプルさを、得ましょうよ！
＃試作WebDesktopServerでは、GUI Widget(に相当する鯖側Object)のポインタをそのまんまHTMLに渡してるんでG7
＃まあ本気で使うときにはHASHかましてセキュリティ向上すべきかなとは思うけどさ。
＃え？「Form1.Button1」とかいう穏当でReadableな名前をHTMLに渡さないのかって？
＃「HTMLは16進ダンプだ」と思えば、そんなことする必要性なんか全然感じないんですけど(^^;
Re:Ajaxってどうですか？ (スコア:1)
WWW上でHTTPを通して接するものとして、そのようにアプリケーション的なものと非アプリケーション的なものが混在することに違和感を覚える層ってのが居るのではないでしょうか。
実際のところはプロトコルが同じであることが問題なのではなく、そういった異なるタイプのリソースにアクセスする手段が共通であることが（意識上で）問題なのだと思います。
「すべてがHTMLに詰め込まれ、HTMLのシンプルさが失われてしまった」という見方も、その表れのひとつでしょう。
しかし、ハイパーリンクでテキストもアプリケーションも繋がるという現実があるという前提で、リンクアンカーやウィンドウ（orタブ）の提示形態、Windowsで言うタスクトレイのようなものの提示など、運用の方でも解決できることだとは思います。
Re:Ajaxってどうですか？ (スコア:0)
はーい。(挙手
構造的にHTTPはいいとしても、なんでリッチクライアント目指すのに、
ペイロードがHTML/XMLなんやねん。
とかも違和感を覚えます。
シームレスなサービスとして提供するにしても、
テキストはテキスト、ポストバックが必要なダイナミックなのは他のもので提供手段が欲しくなる。
# 一部、ない訳
Re:Ajaxってどうですか？ (スコア:0)
Re:Ajaxってどうですか？ (スコア:1)
XMLで取り出す対象のキャッシュ制御をうまくやることで、ブラウザキャッシュを活用できるんですよ。現状のサイトのつくりが未熟なだけでAJAX自体はWebの構造とかけはなれるものではないです。むしろHTMLという単位で分離していたWebリソースを、より細かくできるという面ではWebの理想形に近づく可能性があると思います。
# データもUIも０から全部自分で作るのではなく、すでにいろいろXMLリソースやUIがあってそれを利用できる世界で考えるとよいかと。
Re:Ajaxってどうですか？ (スコア:0)
悪いのかをわかりやすく説明してくだちい。