パスワードを忘れた？ アカウント作成
Close
8726 story

Mozilla、XFormsを実装へ 78

ストーリー by GetSet
新たなる成長のために 部門より

Silphire 曰く、 "Mozilla Foundationは、Mozillaに「XForms 1.0」の機能を追加する、というプレスリリースを出しました（参考リンク：XFormsのプロジェクトページ / 本家ストーリー）
XFormsはXHTML 2.0の一部としても使われる事が決まっており、どういう事ができるのかについては、developerWorksのSVG and XFormsを見るとよく分かるかと思います。SVGとXFormsでこれだけのインターフェースを作れるとなると、MozillaへのXFormsの実装が非常に楽しみですね。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Mozilla、XFormsを実装へ More

  • Native じゃないんで、日本語を貼り逃げ (スコア:5, 参考になる)

    by tty77 (4123) on 2004年08月12日 0時53分 (#604409)
    おまけ
    • dW : XML : SVGとXForms: 入門 [ibm.com]
      2つの技術と、それらをいかに融合するかを知る
    • dW : XML : XForms入門 [ibm.com]
      次世代のWebフォームを利用して、あらゆるプラットフォームに適した拡張可能なオンライン・フォームを作成する
    • RCCはちょっと危険かも。理由:
      • サーバーサイドで処理するならまだいいかもしれないけど、それでもSVG1.2の仕様はでかすぎでカバーできる開発者は限られる。
      • 一方、クライアント側でSVG1.2準拠のビューアが浸透するのは期待できるのか? SVGがXFormsよりもコンシューマ
    • >Native じゃないんで、日本語を貼り逃げ
      どーでもいいが、英語版のドキュメントを書いてる半分以上はNativeじゃないぞ。

  • こんな規格要らないと思う (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2004年08月12日 0時12分 (#604389)
    現在のWebのフォームがここまで普及したのは、
    「単純で、
    　どこでも似たようなかたちで表現される・使用できる」
    ってのが第一の理由だと思う。

    サイトごとにUIの不統一を引き起こし、なおかつデータ
    構造を複雑化する規格の導入がなぜ必要なのだろう。
    そこまでのことをしたいならFlashのほうが先行してい
    て、しかも成功している。

    ほとんどエンジニアの自己満足だと思う。
    • XFormsは見た目だけでなく、構造化されたデータを、構造化されたまま送信できるのがポイントかな、と。
      Flashとは考えているレイヤーが違うのです。

      参考までに、以下にXForms1.0の仕様書にあった概要を引用しておきます。
      “XForms is an XML application that represents the next generation of forms for the Web. By splitting traditional XHTML forms into three parts—XForms model, instance data, and user interface—it separates presentation from content, allows reuse, gives strong typing—reducing the number of round-trips to the server, as well as offering device independence and a reduced need for scripting.”
      http://www.w3.org/TR/xforms/

      ＃実際にHTML Formをいじっていれば、現行のFormじゃ力不足とは感じるはず
      シェア
      親コメント

      • Re:こんな規格要らないと思う (スコア:2, 参考になる)

        by bool (6916) on 2004年08月12日 10時15分 (#604522) ホームページ
        実際にXFormsをいじってみると，サーバ側のCGIでXFormsを動的に生成したり，クライアント側のXFormsプロセッサ上のJavaScriptエンジンなどで動的にXForms,GUIを生成するといった使い方が，とても重要になるという気がしました．XFormsは，スクリプティングを「減らす」ことはできても，「無くす」ことはできない．

        そういう意味では，XForms仕様に限界を感じたときに，どうするかについて，XForms仕様自体が，何らかの指針を示してくれていたら，ありがたいなぁと思いました．
        http://www.surguy.net/articles/clientside-xsl-taglib.xml
        とか．
        シェア
        親コメント
      • FlashもXMLをそのまま通信できるので、構造化された情報を送受信できますよ。
        ただし、多くの場合、情報構造体なんて物を考えてFlashコンテンツ作る人が少ないのと、見た目と情報の乖離が激しい場合が多いので、誤解されやすいのかもしれません。

        ＃だからと言ってActiveXに行く気はしないわけで、xFormsは歓迎です。
        シェア
        親コメント
    • それをいったら、Flashはデザイナーの自己満足だけど?（汗）

      あれのためだけにサーバーに変な小細工しなけりゃならんエンジニアの身になってくれ。
      シェア
      親コメント
      • Flashをリッチクライアントに位置づけた場合のサーバーアプリケーション開発は、Flexでしょう。Flashだけでやってるのはやっぱり半自己満足な世代になりつつあるかもしれません。
    • webは、高望みしたってできることの限界点は低い。 自動車で言えば、webはレーシングカーには絶対成れない。 それを考えずに機能を拡張してもいずれは淘汰されるだけ。

      • Re:webは制限のあるGUIだから (スコア:2, すばらしい洞察)

        by AD (8507) on 2004年08月12日 10時04分 (#604520) ホームページ 日記

        現在のWebの限界点が低いとしても、進化する試みまで否定することはないのでは。

        その昔、Webに動きを与えんと実装されたJavaScriptなる言語は淘汰されたでしょうか。将来的には淘汰されるかもしれません。しかし、JavaScriptの代替になりうる技術開発及び実装がなければ淘汰されることはないでしょう。どんな技術も実装という土壌が整わなければ使い物になりません。現在のWebで満足しないのなら、新しい試みは受け入れるべきかと。結果的に淘汰されるなら、それはそれでよいことかと。

        使用する環境のことを考慮するのはページ記述者に必要な注意であって、ブラウザ側が新しい技術を実装していくことは良いことではないでしょうか。ブラウザは先進的に、ページ記述者は保守的に、というのが望ましい姿だと私は思います。

        ページ記述者は、ブラウザが新しい技術を実装しても、互換性を重視するために旧来の技術を使うことを選べます。現に、私などは互換性を重視してXHTMLではなくHTML4.01を好んで用いています。

        --
        --労使曰く、ひとごとを尽くして神頼み--
        シェア
        親コメント
      • なぜWebは制限のあるGUIなのです？
        シェア
        親コメント
      • ここでいうレーシングカーって、例えばどんなものなんでしょう？
        揚げ足取りとかでなく、単純に気になるので、教えてくれると嬉しいです。
        シェア
        親コメント

        • Re:webは制限のあるGUIだから (スコア:2, 興味深い)

          by lotusseven (18523) on 2004年08月12日 9時30分 (#604507)
          パートのパンチャーさんがＦ１ドライバーとか？
          プロのパンチャーさんは、画面の機能や入力順や反応速度が入力時間に顕著に現れます。
          雇い主は、１件コンマ３秒の短縮が月間パート経費がいくら削減されるか、
          という事を考えて、入力画面の変更依頼があがってくる事もあります。
          （まさにコンマ単位でタイムを削るチューニングをしている感じ）

          とてもブラウザごときに置き換えられるモノではありません。

          #１件コンマ３秒とかはちょっと言い過ぎ
          シェア
          親コメント

      • Re:webは制限のあるGUIだから (スコア:1, すばらしい洞察)

        by Anonymous Coward on 2004年08月12日 2時10分 (#604454)
        Ethernet は、高望みしたってできることの限界点は低い。自動車で言えば、Ethernet はレーシングカーには絶対成れない。それを考えずに機能を拡張してもいずれは淘汰されるだけ。

        とかいう話はかつてよく聞いた気がするけど、いつのまにか10Gすか？
        シェア
        親コメント
  • 素人考えですが、さらにMSIEと表現上の差が出たりしないのでしょうか。
    ちょっと心配です。
    --
    And now for something completely different...

    • Re:Mozilla vs MSIE (スコア:1)

      by ruto (17678) on 2004年08月12日 14時50分 (#604650) 日記
      それが狙いなのかも。
      シェア
      親コメント

    • Re:Mozilla vs MSIE (スコア:0)

      by Anonymous Coward
      そういう事が無いようにするための XHTML 2.0 かと。

      • Re:Mozilla vs MSIE (スコア:3, すばらしい洞察)

        by naruse (12596) on 2004年08月12日 0時17分 (#604393) ホームページ 日記
        XHTML2.0はそういうものではないと思いますが・・・。
        見た目をつかさどるのはCSSです。
        シェア
        親コメント

      • MSIEには (スコア:0)

        by Anonymous Coward
        いつものごとく微妙に互換性がないものを独自実装する悪寒

        • Re:MSIEには (スコア:0)

          by Anonymous Coward
          MicrosoftはXAMLに力を入れるというスタンスでしょ。一方、Mozillaにも既にXULがあるんだけど、XFormsの実装は単にW3C標準をサポートするという以上の意味はないのかなとも思ってみたり。

          • Re:MSIEには (スコア:1, 参考になる)

            by Anonymous Coward on 2004年08月12日 0時32分 (#604398)
            > 一方、Mozillaにも既にXULがあるんだけど、XFormsの実装は単にW3C標準をサポートするという以上の意味はないのかなとも思ってみたり。

            XFormsはサーバへ送るフォームデータのための仕様なので、XULとは用途が違うと思うけど。
            シェア
            親コメント

            • Re:MSIEには (スコア:3, 参考になる)

              by yukichi (12361) on 2004年08月12日 1時10分 (#604420) ホームページ
              XUL + XFormsによる、リッチクライアントの実装を考えているのでは?

              というか、そもそも、この仕様への対応は、そういうエンタープライズ市場への対応を念頭に置いているのだと思います。Mozillaに実装されているにもかかわらず、いまだに活かされていないSOAPなどの実装を活性化させるには、こうした複雑なデータ処理に対応して、力を発揮できることをアピールする必要があるのではないかと。

              そうでなければ、Mozillaを、webブラウザじゃなくて、webサービス用のモジュールとして利用して欲しい、という狙いもあるかもしれないし。
              シェア
              親コメント

              • Re:MSIEには (スコア:3, 興味深い)

                by acute!! (6872) on 2004年08月12日 8時33分 (#604492)
                >そういうエンタープライズ市場への対応を念頭に置いているのだと思います
                同感です。

                現状のWebアプリの弱点は、貧弱なUIと印刷機能ですよね。

                今リッチクライアントの選定を行っているところは、
                多いと思いますけど、ブラウザ標準で、ある程度のことが
                できれば、選択肢は変わってきますね。

                その意味で、webサービス用のモジュールというのは、
                良い方法かもしれないですね。
                Mozillaでブラウザ抜きの配布ライブラリ的なものを
                用意してくれれて、Eclipseのプラグインでも出来れば
                利用は見込めるかも。

                あとは、PDFに頼らずに印刷したいので、
                XML-FOを直接レンダリングできる機能を備えてくれると
                文句無いんだけどなあ。
                シェア
                親コメント

              • XFormsとPaged Media (スコア:2)

                by bool (6916) on 2004年08月12日 10時49分 (#604534) ホームページ
                > あとは、PDFに頼らずに印刷したいので、
                > XML-FOを直接レンダリングできる機能を備えてくれると
                > 文句無いんだけどなあ。

                MozillaはGekkoエンジンなので，XSL-FOよりは，CSS Paged Mediaプロパティ群 [w3.org]のほうが，先に実装されていきそうな感じがしますね．XSL-FOの将来性ってどうなんでしょうか．

                ちなみに，ぼくは今，マークシート印刷原稿の定義ファイル(としても使えるような調査票媒体非依存な設問構造定義ファイル)を，XHTML2+XFormsで記述できるようにしようとしています(開発協力者募集中です! [keio.ac.jp])．ここでは，内部的に，XSL-FOを使っているわけなのですが，ApacheプロジェクトによるXSL-FO実装のFOP [apache.org]には，苦労させられています…．
                シェア
                親コメント

  • 今更かも知れませんが、このトピックについて MozillaZine と MozillaZine 日本語版で記事 / 邦訳記事が提供されています。

    それから、Web Forms 2.0 [whatwg.org] などについて WHATWG [whatwg.org] のメーリングリスト [whatwg.org]で活発な議論が行われています。

  • セキュホの予感 (スコア:0)

    by Anonymous Coward on 2004年08月12日 1時29分 (#604433)
    セキュリティホールの新たな巣窟となる予感・・・・

    と、適当なことを言ってみる。

  • かつてのNetscape 4.xと (スコア:0, 余計なもの)

    by shiraga (14233) on 2004年08月12日 1時40分 (#604438)
    同じ轍を踏みつつあるような…。

  • 無駄骨 (スコア:0)

    by Anonymous Coward on 2004年08月12日 7時21分 (#604478)
    あの、もじらさん、先にSVGを片付けてくださいよ・・・
    実装したって使えないんじゃ誰も相手にしませんよ
typodupeerror

「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」