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)
# Français
Posté par manalfer . Évalué à 1.
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 . Évalué à 1.
(re-)merci d'avance
[^] # Re: Français (suite)
Posté par titititi . Évalué à 1.
# Utilisation ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 7.
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 ours Ours (site web personnel) . Évalué à 3.
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 . Évalué à 7.
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 (site web personnel) . Évalué à 10.
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 . Évalué à 5.
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 . Évalué à 3.
"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 . Évalué à 5.
ok moi je sais ou je vais, ---> []
[^] # Re: Utilisation ?
Posté par Ludovic . Évalué à 2.
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 Babelouest (site web personnel) . Évalué à 3.
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 (site web personnel) . Évalué à 5.
- 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 . Évalué à 5.
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 . Évalué à 5.
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 (site web personnel, Mastodon) . Évalué à 2.
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 (site web personnel) . Évalué à -6.
(Faut aussi dire que c'est pas moi qui fait le boulot)
# Alors comme ça, on s'ra deux :-)
Posté par revponpuneq . Évalué à 5.
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 ruz revr . Évalué à -1.
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 . Évalué à 4.
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 . Évalué à 3.
[^] # Re: Et la sécurité ...
Posté par Ludovic . Évalué à -4.
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 . Évalué à 4.
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 ruz revr . Évalué à 3.
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 . Évalué à 2.
par contre
http://prdownloads.sourceforge.net/owasp/OWASPGuideV1.1.1.pdf?downl(...)
fonctionne
[^] # Re: Et la sécurité ...
Posté par Black Fox . Évalué à 2.
[^] # Re: Et la sécurité ...
Posté par shiva668 . Évalué à 0.
[^] # Re: Et la sécurité ...
Posté par hachesse . Évalué à 10.
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 . Évalué à 2.
Je n'en doute pas, mais ça m'intéresse, quels sont ils?
[^] # Re: Et la sécurité ...
Posté par ours Ours (site web personnel) . Évalué à 0.
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 (site web personnel) . Évalué à 4.
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 maitre_mulot . Évalué à 1.
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 (site web personnel) . Évalué à 4.
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 . Évalué à 1.
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 (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Et la sécurité ...
Posté par _alex . Évalué à 3.
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 (site web personnel) . Évalué à 7.
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.