vendredi 05 septembre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Articles

Liens connexes

Mozilla foundation announces XForms development project (244 hits)
Page bugzilla pour l'implémentation de XForms dans Mozilla (199 hits)
Le projet XForms de Mozilla (332 hits)
Nouvelles "XForms & XML Events deviennent des recommandations W3C" (468 hits)

Dépêche modérée par

Oumph

Dépêche éditée par

Articles : La fondation Mozilla lance un projet pour le support de XForms

Posté par _alex (). Modéré le 16 août 2004.

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.

Mozilla foundation announces XForms development project (244 hits)
Page bugzilla pour l'implémentation de XForms dans Mozilla (199 hits)
Le projet XForms de Mozilla (332 hits)
Nouvelles "XForms & XML Events deviennent des recommandations W3C" (468 hits)

> Lire la suite (37 commentaires, moyenne: 3,1). [dépêche : 845 caractères]

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)

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Français

Posté par manalfer () le 16/08/2004 à 10:12. (lien). É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 manalfer () le 16/08/2004 à 11:10. (lien). É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
- [^]Re: Français (suite)
  
  Posté par titititi () le 17/08/2004 à 10:58. (lien). Évalué à 1.
  merci encore

Utilisation ?

Posté par ploum (page perso, ) le 16/08/2004 à 10:25. (lien). É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 :-)

[^]Re: Utilisation ?

Posté par Philippe SOHM (page perso, ) le 16/08/2004 à 10:32. (lien). É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 hachesse (page perso, ) le 16/08/2004 à 10:55. (lien). É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 Éric (Jabber id, page perso, ) le 16/08/2004 à 10:57. (lien). Évalué à 11.
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 Ludovic Desfontaines (page perso, ) le 16/08/2004 à 11:19. (lien). É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 _alex () le 16/08/2004 à 11:38. (lien). É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 hachesse (page perso, ) le 16/08/2004 à 11:41. (lien). É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 Ludovic Desfontaines (page perso, ) le 16/08/2004 à 12:20. (lien). É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 Cvreer Genzb () le 16/08/2004 à 13:22. (lien). É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 Etienne Juliot (page perso, ) le 16/08/2004 à 12:03. (lien). É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 hachesse (page perso, ) le 16/08/2004 à 12:37. (lien). É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 _alex () le 16/08/2004 à 12:41. (lien). É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 LupusMic (page perso, ) le 16/08/2004 à 13:51. (lien). É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 VACHOR (page perso, ) le 16/08/2004 à 10:30. (lien). É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 revponpuneq () le 16/08/2004 à 10:51. (lien). É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 duffman () le 16/08/2004 à 12:07. (lien). É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 Pinaraf (Jabber id, ) le 16/08/2004 à 12:17. (lien). É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 Ozz () le 16/08/2004 à 12:23. (lien). Évalué à 3.
  ben une vérification coté client est facilement contournable.
- [+] [^]Re: Et la sécurité ...
  
  Posté par Ludovic Desfontaines (page perso, ) le 16/08/2004 à 12:24. (lien). É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 maitre_mulot (page perso, ) le 16/08/2004 à 12:28. (lien). É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 duffman () le 16/08/2004 à 12:35. (lien). É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 maitre_mulot (page perso, ) le 16/08/2004 à 12:50. (lien). Évalué à 2.
      le lien ne marche pas chez moi.
      par contre
      http://prdownloads.sourceforge.net/owasp/OWASPGuideV1.1.1.pdf?downl(...)
      fonctionne
    - [^]Re: Et la sécurité ...
      
      Posté par Black Fox (page perso, ) le 18/08/2004 à 12:15. (lien). Évalué à 2.
      Note que ça se valide aussi coté serveur, l'avantage est pour le client de ne pas avoir à envoyer de donnés avant d'être sur que c'est bon (pas de rechargement de pages tout ça...)

[^]Re: Et la sécurité ...

Posté par shiva668 () le 16/08/2004 à 12:27. (lien). É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 hachesse (page perso, ) le 16/08/2004 à 12:47. (lien). É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 tene (page perso, ) le 16/08/2004 à 19:16. (lien). É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 Philippe SOHM (page perso, ) le 17/08/2004 à 17:28. (lien). Évalué à 0.
    bah le seul défaut que je vois est que tu as une variable d'état (__VIEWSTATE) qui grossit au fil du nombre de contrôles et des données enregistrées.
    mais bon après si la bp augmente c'est pas très grave, et vaut mieux payer de la bp que des jours de développement.
    
    après les contrôles sont très bien foutus, ASP .Net 2.0 va visiblement être un grand cru avec de nouveaux contrôles.
    j'ai pas encore installé la bêta de Visual Studio 2005 (Whidbey) mais ca risque d'être chaud pour Eclipse.
    
    Pour ceux qui veulent plus d'infos : http://lab.msdn.microsoft.com/vs2005/(...)
    http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx(...)

[^]Re: Et la sécurité ...

Posté par Dinofly (page perso, ) le 16/08/2004 à 13:06. (lien). É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.

--
Je connais bien l'algèbre de Boole, et j'ai même vu tous ses flims.
- [^]Re: Et la sécurité ...
  
  Posté par maitre_mulot (page perso, ) le 16/08/2004 à 13:15. (lien). É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 Benoît Sibaud (Jabber id, page perso, ) le 16/08/2004 à 13:46. (lien). É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 maitre_mulot (page perso, ) le 16/08/2004 à 15:22. (lien). É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 LupusMic (page perso, ) le 16/08/2004 à 14:05. (lien). É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 _alex () le 16/08/2004 à 14:46. (lien). É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 XHTML/CSS inside (page perso, ) le 16/08/2004 à 19:00. (lien). É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.

--
In tartiflette we trust !

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Dépêche éditée par

Articles : La fondation Mozilla lance un projet pour le support de XForms

Français

[^]Re: Français (suite)

[^]Re: Français (suite)

Utilisation ?

[^]Re: Utilisation ?

[^]Re: Utilisation ?

[^]Re: Utilisation ?

[^]Re: Utilisation ?

[^]Re: Utilisation ?

[^]Re: Utilisation ?

[^]Re: Utilisation ?

[^]Re: Utilisation ?

[^]Re: Utilisation ?

[^]Re: Utilisation ?

[^]Re: Utilisation ?

[^]Re: Utilisation ?

[+] Oui

Alors comme ça, on s'ra deux :-)

[+] Et la sécurité ...

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...

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

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...

[^]Re: Et la sécurité ...