パスワードを忘れた? アカウント作成
12482 story

AdobeがAjaxのフレームワーク「Spry」プレビュー版をリリース 11

ストーリー by mhatta
そう来ましたか 部門より

pivo曰く、"ITmediaの速報にも掲載されているが、AdobeがAjax用のフレームワーク「Spry」のプレビュー版をリリースした。 Adobe LabsのサイトにデモやFAQなどがあり、ダウンロードも可能。

リリースノートを見ると、BSD licenseのようだ。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by hiropbg4 (15084) on 2006年05月13日 12時59分 (#938358)

    Yahoo!ではYahoo! User Interface Library [yahoo.com]というものを以前から配っていて、個人的には重宝しています。最近メニューやダイアログ、自動補完といったものが拡充されてさらにいい感じになりました。
    以前Googleの人が「Yahoo!と違ってうち(Google)はデベロッパの人たちに対して公開してるAPIも少ないし、あんまメンテしてないんだよねぇ」と言ってたので、逆にYahoo!はそこら(Yahoo! Developer Network [yahoo.com])でも差別化を図りたいのかもしれません。ちなみにこれ、BSDライセンスです。

    これくらいならソース書く方もずいぶん楽だなぁという感想を持ったのですが、Adobeはさらに抽象度の高いところで攻めてくるんですね。エントリユーザ向けというか、DreamWeaverにすぐに入れられるようなコンポーネントと言うか。
    あと、やっぱりPhoto Albumは外せないかーなんてふつーのことを思ったりしました。

  • 正しいHTML (スコア:3, 興味深い)

    by yasu (7) on 2006年05月12日 21時46分 (#938041) ホームページ

    spryregionとか、spryifとかの標準ではない属性を使うのは気持ち悪いかなぁ。NSを分けて、spry:region, spry:if みたいに出来るといいんですが。

    --
    HIRATA Yasuyuki
  • by kanekiyo (30828) on 2006年05月12日 18時19分 (#937923)
    jsを使ったEffect集のライブラリはいろいろと見かけるけど、Datasetまでフレームワークで定義してあるのは新しいかも。ここら辺のデファクト争いは今後激化しそうな感じだね。
  • by kayama (22142) on 2006年05月13日 0時23分 (#938136) 日記
    w3mを使うことも多い人間としては複雑な心境です。
    ブラウザおよびそのバージョンへの依存性が高まるのも厄介だと思います。
    テストも容易ではないし。
    JavaScriptなしでも最低限の機能は使える仕組みだといいんですけれど。
    • by Anonymous Coward on 2006年05月13日 2時10分 (#938191)
      たとえば Ajax 実装のワープロアプリに
      テキストベースのドキュメント性を求めても
      仕方ないですよね。
      アプリケーションであろうとしているものが
      表現しているものはそもそもドキュメントではないですから。

      そういうものを w3m で閲覧したいということに
      無理があるということになるのだと思います。

      今後は、あるページが表現しようとしているものが
      ドキュメントなのか、
      ブラウザベースのアプリケーションなのかを
      分けて考える必要があるでしょうね。

      互換性やテスト性は、Ajax フレームワークで
      解決していくと期待したいです。
      親コメント
      • by kayama (22142) on 2006年05月13日 10時58分 (#938301) 日記
        SpryのデモアプリケーションにPhoto Galleryがありますが、
        こういったアプリケーションが達成すべき最低限の機能、たとえば単なるサムネールの表示や画像の選択はHTML標準で実装できるんです。

        ところがユーザビリティを向上しようとしてAjaxを導入すると、
        HTML標準から外れてしまうに留まらず、強いブラウザ依存性も発生します。
        たとえば件のSpryは、現時点でOperaへの対応をうたっていません。

        JavaScriptがオプショナルを越えて必須になってしまうのは、果たして正しい進歩なのだろうか?
        Ajaxアプリケーションは、必要な堅牢さ・保守性を獲得できるのだろうか?
        というのがAjaxに対する私の疑問です。

        クライアントがJavaScriptをサポートしない場合に、サーバサイドのJavaScript実行にフォールバックできれば、
        ユーザビリティを犠牲にするだけで最低限の機能は達成できるかな? とか妄想はしています。
        親コメント
        • 違うものを同じものとして議論しようとしても無駄だと思いますよ。

          Ajaxという名前で一気に機運が高まりましたけど、ようするにこれはHTML+JavaScriptによるアプリケーションです。その実行環境は何もIEやFirefoxのようなブラウザじゃなくてもいいわけです。
          ちなみにJavaScriptもECMAScriptという名前で標準化されている技術です。
          それにHTMLである必要はないんですよね。見た目はCSSで定義できるのだから、構造はXMLで書けばいい。後付けのいいわけっぽいですけど、XMLのサブセットであるHTMLを使った方がめんどくさくないというだけではないかと。

          そしてUIをXMLで記述するというのは、Firefox/Thunderbirdを動かしてるXULが有名ですが、確かマイクロソフトもXMLでUIを定義すると聞いています。つまりはひとつの潮流としてXMLによるUIというのはある。そしてその見た目を定義するものとして、CSSというものが既に標準化されたうえで存在している

          さらにもっと言えば、XMLとCSSとECMAScriptという三つの標準化された規格があって、そのすべてに対応してる実装が複数存在している。
          しかもいまどきのコンピュータにはたいていそのどれかは入っている!
          これを利用しない手は無いわけです。

          だからこれはHTML標準とは実はあまり関係無い。ブラウザ対応云々という問題ではなく、XMLとCSSとECMAScriptの標準に準拠してるかどうか、という問題。

          たいしてw3mはブラウザですらなく、HTTPを喋るページャです。実は私の環境変数PAGERもw3mになっています。

          HTML標準準拠は重要なことですが、JavaScriptで動的に書き換えられるだけでHTML標準が崩れるわけじゃないですよね。書き換えられたあとのHTML構造が検査しにくいってのはあるでしょうけど。
          親コメント
        • 結局は、分化なんではないでしょうか?

          IPの上にTCPやUDPがあるように、
          TCPの上にHTTPやFTPがあるように、
          HTTPに、HTMLDocumentとWebApplicationがあるわけで、

          HTTPにもう1種類ぐらいのったって、
          どうという事はないのではないでしょうか?

          Ajaxなんか、そんなもんって事でどうでしょう。
        • 「正しい」ってのが何なのかわかりませんが、
          企業の論理としてはデファクトスタンダードを握ることが何より重要です。
          デファクトを握れば、Operaに対応させる必要はありません。
          Operaが対応してくれるのですから。

          #もちろん誰もデファクトを握れなくてDHTMLの二の舞ってことも十分ありえます
typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

読み込み中...