La fondation Mozilla lance un projet pour le support de XForms

Posté par  . Modéré par Benoît Sibaud.
Étiquettes : aucune
0
16
août
2004
Mozilla
Mercredi dernier, la fondation Mozilla a lancé un projet pour intégrer le support natif de la recommandation W3C XForms dans son navigateur.

Il manque encore beaucoup d'étapes avant qu'une première version ne soit prête (validation XMLSchema par exemple) mais le projet est lancé.

Pour mémoire, XForms permet de faire de la saisie de document XML avec une séparation entre les données et la présentation. XForms fonctionne du coté client. Dit autrement, on peut considérer XForms comme un formulaire HTML, avec :
- la vérification des données saisies côté client
- l'envoi d'un document XML plutôt qu'une myriades de variables post/get

http://www.w3schools.com/xforms/default.asp est un tutoriel en anglais sur XForms.

http://www.yoyodesign.org/doc/w3c/xforms-for-html-authors/ : ce document en français décrit comment passer des formulaires HTML à XForms.

Pour le navigateur de Microsoft, il existe un plugin payant : http://www.formsplayer.com/

Il existe aussi des implémentations coté serveur comme Chiba : http://chiba.sourceforge.net (Open Source)

Aller plus loin

  • # Français

    Posté par  . Évalué à 1.

    Mercredi dernier, la fondation Mozilla a lancé un projet pour le support natif de la recommandation W3C XForms dans son navigateur

    ou :

    Mercredi dernier, la fondation Mozilla a lancé un projet pour que le support natif de la recommandation W3C XForms soit intégré dans son navigateur

    merci
    • [^] # Re: Français (suite)

      Posté par  . Évalué à 1.

      Mercredi dernier, la fondation Mozilla a lancé un projet pour intégrer le support natif de la recommandation W3C XForms dans son navigateur.

      (re-)merci d'avance
  • # Utilisation ?

    Posté par  (site web personnel, Mastodon) . Évalué à 7.

    Question :

    Si ça marche, sachant que seul un plugin payant est dispo pour IE, est-ce que cela serait utilisé ?

    En gros cela vaut-il la peine d'investir dans cette direction ?

    (je n'ai honnêtement aucune idée. Je pose ouvertement la question car je crois ne pas être le seul à ne pas connaitre Xform)

    PS : merci à l'auteur de la news pour son explication claire :-)

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: Utilisation ?

      Posté par  (site web personnel) . Évalué à 3.

      en interne oui.
      en externe probablement pas, ca mettra beaucoup de temps pour avoir une base utilisateurs sufisamment grande pour s'imposer.

      C'est à rapprocher de toutes les nouvelles technos Web qui demandent une implémentation cliente évoluée - ou particulière - comme le CSS 2.0, du XUL, Java sur applet (pluralité des versions sur les ordinateurs).
      • [^] # Re: Utilisation ?

        Posté par  . Évalué à 7.

        Ca mettra du temps, certes mais ca devrais (doit !) marcher pour tout le monde.

        Les XForms ont un énorme avantage par rapport au formulaire actuels c'est la prise en compte des différents support de presentation.

        En effet les formulaires HTML tel qu'on les connais aujourd'hui sont apparu a une époque ou la seule facon d'afficher une pase web, c'etait d'avoir un ordinateur et un écran 14 ou 15 pouces sous la main.

        Mais avec l'evolution des plateforme mobile, on peu naviguer partout et sur différent type de support avec des ecrans de toute les tailles.

        Si du simple texte XHTML mis en forme grace a des CSS s'affiche tres bien sur un telephone ou un PDA, ce n'est pas la meme chose avec les forumulaires qui sont parfois inutilisable.

        XForm devrais apporter une reponse a ce probleme en laissant le client gerer lui meme l'affichage du forumulaire aussi que la saisie et le control d'information

        Par ailleurs, il est aussi a noter qu'il existe plus qu'un plug in pour IE qui intègre cette norme

        http://www.w3.org/MarkUp/Forms/#implementations(...)
    • [^] # Re: Utilisation ?

      Posté par  (site web personnel) . Évalué à 10.

      En même temps si tu ne fais rien qui ne marche sur MSIE6, on peut déjà arrêter tout développement sur Mozilla, et toute étude au W3C. Exit XUL, CSS3, XHTML2 et tout le reste.
      Pourquoi prendre un navigateur déjà vieux de plusieurs années pour savoir ce qu'on implémentera dans 1 à 3 ans ?
      Les utilisateurs n'aiment pas changer leurs logiciels mais je t'assure que si pour visiter les sites ils ont besoin de changer ou d'installer un plugin ils le feront. Comme ils le font déjà pour flash et tout le reste
      • [^] # Re: Utilisation ?

        Posté par  . Évalué à 5.

        Je suis d'accord avec toi sur le fond.

        Si tu leur dis, il faut ça, mais c'est payant. Ils ne vont pas chercher plus loin ils vont abandonner la page.

        Si tu leur dis, qu'il existe une solution alternative, à installer, totalement gratuite, il n'est pas certain qu'ils iront l'installer. Il ne faut pas oublier que tout ce que recherche la majorité des utilisateurs (à l'heure actuelle), c'est la simplicité ! Et malheureusement, notamment à cause des contrôles ActiveX, IE reste nécessaire sous $dows. Et il ne faut pas aller dire à l'utilisateur : "alors pour ça, c'est mozilla, mais pour ça, c'est IE. Pour le mail de truc, c'est thunderbird, mais pour le mail de tel boîte, c'est Out...(brrr, j'arrive pas à le dire)".

        Il ne faut tout de même pas oublier qu'à l'heure actuelle, IE étant installé par défaut avec tous les $dows, il reste le navigateur dont tous le monde se soucie.

        Le seul cas où la perennité de ce produit serait assuré, c'est dans le cas où des plugins GRATUITS se trouveraient disponible, aisement.
        Limite officiel !

        Oila ++
        Ludo
        • [^] # Re: Utilisation ?

          Posté par  . Évalué à 3.

          J'ai parlé de FormsPlayer pour Internet Explorer parce qu'il me semble un des projet les plus actifs, peut être que je me trompe. En tout cas il existe d'autres projets; par exemple Mozquito DENG ( http://sourceforge.net/projects/dengmx(...) ) :
          "DENG is a modular class library written in OOP Actionscript 1, turning the Macromedia Flash Player 6 into a webbased, zero-install, cross browser/platform, modular and standards compliant XML/CSS2 browser."

          Concrétement, Mozquito peut afficher un XForms en utilisant Flash 6. Et la, c'est gratuit.

          cf http://claus.packts.net/deng/examples/(...) pour des exemples.
          • [^] # Re: Utilisation ?

            Posté par  . Évalué à 5.

            Si on commence a pluguer les navigateurs pour pouvoir lire du flash et a pluguer flash pour afficher les XForms, on va t'on

            ok moi je sais ou je vais, ---> []
            • [^] # Re: Utilisation ?

              Posté par  . Évalué à 2.

              Clair. Tu as raison (pas de sortir hein :) )

              Flash doit se contenter de faire du flash.
              S'il faut un truc, qui part une bidouille ignoble, réussi à lire un format (libre de surcroît, pas comme Flash), autant oublier le développement de ce truc.

              Il faut un truc simple, pas de "je passe par Marseille pour arriver à Paris, en partant de Lille" !!
              • [^] # Re: Utilisation ?

                Posté par  (site web personnel) . Évalué à 3.

                Pourquoi tu veux partir de Lille ?
                A plus forte raison pour aller a Paris...

                Avant de sortir (j'ouvre le battant de la porte ->[ | ), je voudrais savoir un petit truc, ce format est-il pieds et poings liés aux navigateurs, ou peut-on l'utiliser dans d'autres cas non Web, voire non client/serveur ?
    • [^] # Re: Utilisation ?

      Posté par  (site web personnel) . Évalué à 5.

      Tu peux aussi avoir le scénario suivant :
      - la requete est reçu sur le serveur
      - si c'est gecko avec support XForms:
      -> tu renvoies le xhtml avec xforms dedans
      - si c'est ie
      -> tu fais une transformation côté serveur (avec xslt par exe) du xhtml + xforms en xhtml + form classique
      -> tu renvoie une page classique au browser

      Comme ca, c'est transparent pour tout le monde.

      C'est déjà un peu comme ça que fonctionne Cocoon (projet Java Apache) pour décider d'envoyer telle ou telle page en fonction de tel navigateur (si besoin bien sur).
      • [^] # Re: Utilisation ?

        Posté par  . Évalué à 5.

        Le probleme de ce genre de chose, c'est que tu developpe 2 fois ton site.

        Et puis dans ce cas, pourquoi utiliser un standard, si c'est pour generer un code différent suivant ton client, t'as plus besoin de standard.

        Modifier aurant de fois ton code que tu supportes de navigateurs a chaque modification, quelle perte de temps.
        • [^] # Re: Utilisation ?

          Posté par  . Évalué à 5.

          Il n'y a qu'un seul code : le source XForms.
          Les transformations et tout le toutim sont gérées par Cocoon. Il doit assez simple de faire la même chose avec Chiba (plus léger que Cocoon si c'est interpréter du XForms).
          NB: XForms est une recommendation seulement depuis l'an dernier, il faut un peu de temps...
        • [^] # Re: Utilisation ?

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          C'est pour ça que XSLT ça roxor !

          D'ailleurs, on pourrait faire une feuille XSLT qui transforme un document XForm en un fichier XHTML lié à un fichier de scripts (javascript) qui permet de controler que les expressions régulières sont respectées.

          C'est pas optimal (surtout que nombre d'entre-nous coupons le Javascript), mais ça peut être intéressant pour normaliser les formulaires entre plusieurs version d'un même produit (portail Wap, i-mode, SOAP, etc...).
  • # Oui

    Posté par  (site web personnel) . Évalué à -6.

    Je suis pour. Au cas où cela marcherait ...
    (Faut aussi dire que c'est pas moi qui fait le boulot)
  • # Alors comme ça, on s'ra deux :-)

    Posté par  . Évalué à 5.

    Je pense que c'est une très bonne idée ! D'ailleurs, le projet Mozilla n'est pas le seul à y penser :

    http://specs.openoffice.org/appwide/xforms/GUI_spec_part1.sxw(...)

    http://specs.openoffice.org/appwide/xforms/GUI_spec_part2.sxw(...)


    --
    eric bachard (et pas "erici bachelard". Merci )
  • # Et la sécurité ...

    Posté par  . Évalué à -1.

    la vérification des données saisies côté client


    Voir qu'il y a encore des gens qui peuvent penser que la vérification côté client soit quelque chose de sensé me fait bondir. Et en plus c'est une recommendation W3C ...
    • [^] # Re: Et la sécurité ...

      Posté par  . Évalué à 4.

      Peux tu argumenter s'il te plaît ?
      Perso je vois ça d'un bon oeil : code serveur moins lourd, moins de requêtes inutiles (envoyer un message pour dire : "ha ben oui tu as mal rempli" ça me gonfle)...
      • [^] # Re: Et la sécurité ...

        Posté par  . Évalué à 3.

        ben une vérification coté client est facilement contournable.
      • [^] # Re: Et la sécurité ...

        Posté par  . Évalué à -4.

        Entièrement d'accord.
        Il est beaucoup plus :
        - rapide
        - économique en BP
        d'effectuer le contrôle chez le client.

        Il faut arrêter de dire que c'est "anti-sécurité".
        Tu peux continuer à charger ton serveur si ça te fait plaisir mais bon, à moins que tu ais de la bande passante à bouffer, il est temps de revoir sa politique ...

        ++
        Ludo
        • [^] # Re: Et la sécurité ...

          Posté par  . Évalué à 4.

          Surtout que 'normalement' tu fais un controle cote client ET cote serveur.
          Et a developper c'est super lourd.

          Si on peut faire le controle cote client et que ca n'utilise pas du javascript(facilement desactivable) alors c'est une bonne chose je pense.
        • [^] # Re: Et la sécurité ...

          Posté par  . Évalué à 3.

          La vérification côté client est facilement contournable (programmation d'un client différent, modification du code du logiciel client pour désactiver la vérification, utilisation d'un proxy modifiant la requête ...).

          On ne peut jamais être sur que le client va envoyer des informations correctes et il faut donc *toujours* les vérifier côté serveur (on peut aussi parfois le faire côté client pour des raisons d'ergonomie).

          Un petit lien pour finir :
          http://heanet.dl.sourceforge.net/sourceforge/owasp/OWASPGuideV1.1.1(...)
          chapitre 10
    • [^] # Re: Et la sécurité ...

      Posté par  . Évalué à 0.

      Voir qu'il y a encore des gens qui peuvent balancer des remarques à l'emporte piece dans le style sans meme se donner la peine d'argumenter un tant soit peut me fait bondir.
    • [^] # Re: Et la sécurité ...

      Posté par  . Évalué à 10.

      La vérification coté client le sert qu'a une seule chose : ne pas rechercher la page pour les controles de base.

      Recharger une page, ca coute cher en temps, en bande passante, en charge pour le serveur, et ce n'est pas trop economique.

      Mais les controle coté clients ne sont pas fait pour remplacer les controle coté serveur.

      Coté client, tu peux verifier sur tout les infos obligatoires sont bien saisies et si leur format semble correct.

      Une fois sur le serveur, tu refais ces controles et en plus tu teste la validité des infos.

      Les controles web ASP.NET, on plein de defaut, mais ils ont par contre cette qualité c'est de permettre la mise en place de ces controles de facon tres simple pour le developpeur.
      • [^] # Re: Et la sécurité ...

        Posté par  . Évalué à 2.

        "Les controles web ASP.NET, on plein de defaut,"

        Je n'en doute pas, mais ça m'intéresse, quels sont ils?
    • [^] # Re: Et la sécurité ...

      Posté par  (site web personnel) . Évalué à 4.

      Ca n'empeche pas de faire une vérification côté serveur par la suite... mais c'est quand même beaucoup plus pratique de ne pas avoir à charger une nouvelle page pour voir un message "vous n'avez pas correctement rempli le champ bidule !".

      Aujourd'hui on vérifie en Javascript ET côté serveur, demain on remplace juste Javascript par XForms mais on garde le côté serveur.
      • [^] # Re: Et la sécurité ...

        Posté par  . Évalué à 1.

        Il n'existe rien qui permette d'ecrire une seule fois la facon de verifier qu'une date est bien une date et que cela soit genere cote client et cote serveur?

        Doit bien y avoir un projet qui traine non?

        Car la validation cote client/serveur faut avouer que c la barbe
        • [^] # Re: Et la sécurité ...

          Posté par  (site web personnel) . Évalué à 4.

          Les vérifications ne sont pas du même type en général.
          Par exemple pour ce commentaire, côté client, je peux vérifier que le titre et le corps sont non vides, et qu'ils ne contiennent que de l'ISO8859-15 par exemple. Côté serveur, je vais vérifier que le commentaire provient bien d'un utilisateur identifié, avec une session valide, qu'il a le droit de proposer un commentaire, qu'il s'agit d'une réponse à un commentaire valide et accessible avec ses droits, que le titre et le corps sont non vides, qu'ils ne contiennent que de l'ISO8859-15, qu'ils ne contiennent pas de code non désiré, que la longueur est correcte, etc.
          • [^] # Re: Et la sécurité ...

            Posté par  . Évalué à 1.

            je suis bien d'accord, mais cote serveur tu devras tout de mm reverifier que le titre et le corps sont non vides et ...

            C'est ca qui est embetant je trouve (je ne fais que des jsp), toujours avoir a ecrire 2 fois la mm chose
        • [^] # Re: Et la sécurité ...

          Posté par  (site web personnel, Mastodon) . Évalué à 3.

          Il suffit de générer le code Javascript en même temps que le code PHP.
        • [^] # Re: Et la sécurité ...

          Posté par  . Évalué à 3.

          Les formulaires XForms produisent des documents XML, et la validations se fait par rapport à un XML Schema (ou une grammaire définie dans le XForms).

          En d'autre terme, savoir si ce que donne l'utilisateur est valide revient à savoir si le document XML produit est conforme à une grammaire XML.

          Et ça, il y a un bon paquet de parsers XML qui savent le faire.

          La grammaire XML ne fait pas tout (je pense par exemple à un champs PCDATA assez compliqué), mais ca aide beaucoup comparé à un ensemble de variables post/get récupéré par une page PHP/ASP/JSP/CeQuOnVeut.

          Rien à voir par à la validation :
          Chiba qui fonctionne coté serveur avec une servlet, utilise un XSLT pour produire le document HTML. Dans les dernières versions il est possible d'utilisé des XSLT différents en fonction du navigateur.
          -->
          - Ca permet par exemple d'envoyer du XForms directement pour Mozilla lorsqu'il le supportera
          - Ca permet d'afficher les contrôles XForms sous la forme que l'on veut. Et éventuellement de faire de la validation coté client avec du javascript.
    • [^] # Re: Et la sécurité ...

      Posté par  (site web personnel) . Évalué à 7.

      >Voir qu'il y a encore des gens qui peuvent penser que la vérification côté client soit quelque chose de sensé me fait bondir. Et en plus c'est une recommendation W3C ...

      Voir ce genre de propos non argumenté me fait bondir !

      C'est tout à fait sensé : il faut penser aussi aux possesseurs de petites connexions, qui trouveront bien agréable de ne pas devoir recharger la page pour un champ oublié/mal rempli, et pour cela, javascript est bien pratique et facile à mettre en oeuvre.
      Et cela ne surcharge pas le serveur de requêtes facilement évitables.

      Bien sûr, il faudra tout vérifier côté serveur après.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.