Articles précédents : Logiciel
- [33] Skype pour Linux !
- [18] Glom : une interface pour PostgreSQL
- [82] Sortie d'OpenOffice.org 1.1.2
- [8] POV-Ray 3.6.0 disponible !
- [13] Un petit tour d'horizon des logiciels d'astronomie sous Linux
- [76] Les ISO de SuSE 9.1 version personnelle sont enfin disponibles...
- [140] Ça bouge du côté de SQLite !
- [81] Sortie de Mozilla 1.7
- [49] Amarok 1.0 est là !
- [53] Premier jeu de cartes en SVG pur
Liens connexes
Dépêche modérée par
Logiciel : Formsess, pour les formulaires et les templates
Posté par Vincent F. (). Modéré le 23 juin 2004.
Rien d'exceptionnel me direz-vous, mais ses capacités sont assez intéressantes... En effet, il génère les formulaires via une syntaxe XHTML, il vérifie les données du côté client (via JavaScript) et du côté serveur (PHP), construit des messages d'erreurs personnalisés, et enfin analyse la persistance des données.
En bref, un bon outil pour développeur web, qui mérite d'être cité pour sa qualité et son côté pratique...
![[en]](../../../images/en.png)
> Lire les commentaires (16 commentaires, moyenne: 3,2).
Et QuickForm
Dans le même genre, il y a Pear QuickForm et Quickform Controller qui ont l'avantage d'être compatibles avec un grand nombre de moteurs de templates.
http://pear.php.net/manual/en/package.html.html-quickform.php(...)
PS: puisque c'est un projet français, pourquoi le site et la doc sont exclusivement en anglais ?
-
[^]Re: Et QuickForm
Posté par Cali_Mero () le 23/06/2004 à 21:00. (lien). Évalué à 6.Il y a aussi OOhForms, de phplib (l'autre pays du fromage grosse bibliothèque de code php) :
PHPLib : http://phplib.sourceforge.net/(...)
OOHForms : http://www.sanisoft.com/phplib/manual/oohforms.php(...)--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */
gestionnaire de formulaire ?
Je ne comprend pas très bien le rôle de ce genre de logiciel ni ses avantages (pourtant j'ai l'intuition que ça pourrait me donner de grands coups de main). Est-ce qu'une bonne âme pourrait tenter une explication ?
-
[^]Re: gestionnaire de formulaire ?
Posté par XHTML/CSS inside (page perso, ) le 23/06/2004 à 23:09. (lien). Évalué à 6.Vois-tu, quand je dois pondre une interface d'admin pour un site, il faut que je fasse environ 15 fois la même chose, donc comme l'idée est de gagner du temps sur les tâches "pénibles", autant que ça soit la machine qui le fasse (la machine ne se trompe jamais et ne fait pas de fautes de frappe, si tu vois ce que je veux dire).
A titre d'exemple, je me suis créé mon propre mini-générateur de formulaires, qui me fait le sale boulot. (du moins une bonne partie)
http://dominique.hoffmann.free.fr/SOC/(...) (une version démo en cours d'amélioration)
Cela ne paraît pas avec 3 champs, mais devoir se farcir un formulaire de 50 champs avec les requêtes qui vont avec à la mano, c'est vraiment pénible.
Alors qu'avec ce petit utilitaire, je gagne au moins un tiers du temps pour créer une interface d'admin, avec moins de bugs.--
In tartiflette we trust !
-
[^]Re: gestionnaire de formulaire ?
Posté par Cali_Mero () le 23/06/2004 à 23:35. (lien). Évalué à 10.Je tente :
Quand tu as fait deux sites webs (certains s'en apercoivent meme avant, d'autre après...), tu constates que certaines tâches sont à la fois particulièrement sensibles et répétitives à la fois : exemple, un formulaire permettant de s'inscrire à une mailing-list. un bête champ de saisie de texte et un bouton me diras-tu.... Oui, mais encore faut-il pouvoir vérifier que l'utilisateur ne rentre pas n'importe quoi pour que les données en base, nourries par le formulaire, restent valides. Et la validation d'une adresse e-mail est sans doute l'exemple le plus typique de tâche répétitive qu'on a à faire sur quasiment tous les sites webs.
Il est donc intéressant de se tourner vers ce type de logiciel qui te propose des méthodes unifiées pour :
- générer le code (x)HTML de tes formulaires
- Recevoir et traiter les données après la soumission du formulaire
- valider les données côté client et fournir des tests javascript adaptés
- valider également côté serveur (la validation javascript n'étant qu'un confort pour l'utilisateur et aucunement une sécurité)
- gérer intelligemment les erreurs (l'utilisateur s'est trompé dans son mot de passe ? ok, on lui redemande le mot de passe, mais pas besoin de lui faire resaisir son login, alors on réaffiche le login et on balance un message d'erreur adapté au pépin).
Tout ceci non seulement doit marcher impeccablement bien, pour la sécurité de ton site et le confort du visiteur, mais aussi fait appel à des compétences pointues en (x)HTML pour créer les formulaires, en PHP pour gérer les données et valider coté serveur, en javascript pour les messages d'erreur et le premier niveau de validation... C'est complexe et tout refaire à chaque site prend beaucoup de temps et entraine le risque d'une erreur qui peut tout faire péter (une possibilité d'injection SQL suite à des données mal ou pas validées par exemple).
Voilà pourquoi il est intéressant de se tourner vers ce type de programme, orienté composants. En gros, tu te bornes à dire "Je veux un champ de texte qui s'appelle email et qui doit être rempli avec une adresse email" et le programme se charge quasiment de tout le reste. C'est un gros gain de temps, surtout sur des formulaires complexes.
PS : ce genre de système devient encore plus intéressant s'il est extensible et s'il te permet de développer tes propres composants pour les utiliser selon le même schéma que les champs de formulaire ordinaires du HTML (par exemple : un wysiwyg, un calendrier...).--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */-
[^]Re: gestionnaire de formulaire ?
Posté par Mildred (Jabber id, page perso, ) le 23/06/2004 à 23:46. (lien). Évalué à 3.Le problème avec tout les scripts php trouvés sur Internet c'est que je n'arrive jammais à les intégrer à mon site.
Sauf wiki2xhtml et maintenant WikiRender-
[^]Re: gestionnaire de formulaire ?
Posté par Julien Duponchelle (page perso, ) le 24/06/2004 à 06:01. (lien). Évalué à 2.Regarde du coté de PEAR (http://pear.php.net/(...)) se sont des classes PHP facile à utiliser et généralement correctement documenté.
-
[^]Re: gestionnaire de formulaire ?
Posté par account () le 24/06/2004 à 07:08. (lien). Évalué à 3.Et est-que les classes PEAR sont utilisable chez Free ? Perso, je n'y suis pas arrivé...
-
[^]Re: gestionnaire de formulaire ?
Posté par Julien Duponchelle (page perso, ) le 24/06/2004 à 19:19. (lien). Évalué à 1.je pense que oui, perso j'embarque avec mes scripts tous les morceau de PEAR dont j'ai besoin sans utiliser ceux du serveur
-
-
-
-
[^]Re: gestionnaire de formulaire ?
Posté par Aurélien Girard () le 24/06/2004 à 08:17. (lien). Évalué à 2.Ah, c'est donc bien ce que je cherche.
Mais comment est-ce que ça marche ? Est-ce qu'on gagne vraiment beaucoup de temps ?-
[^]Re: gestionnaire de formulaire ?
Posté par Cali_Mero () le 24/06/2004 à 14:35. (lien). Évalué à 2.Mais comment est-ce que ça marche ?
C'est au cas par cas suivant l'appli que tu choisiras... souvent c'est intégré à un moteur de templates pour la génération HTML/JS, les traitements étant gérés via un objet global (formulaire) avec des sous-objets (les champs). Mais je n'ai pas étudié le cas particulier de celui-là.
Est-ce qu'on gagne vraiment beaucoup de temps ?
Au début non, il faut apprendre à se servir de l'outil qui peut paraître exotique (c'est quand même assez abstrait). Mais dès la deuxième utilisation, quand tu commences à maîtriser la chose, les avantages apparaissent clairement et le gain de temps est réel, sans compter la maintenance ultra-aisée et unifiée sur l'ensemble de tes sites utilisant ce type de soft (si un test d'email est incomplet ou pose problème, il est facile de le modifier et/ou de l'étendre en répercutant directement les modifs sur l'ensemble de tes créations).--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */
-
-
et / phpforgen ?
pour les moteurs de formulaires, y a aussi PHPFromGenerator (http://phpformgen.sf.net/(...) mais qui doit être moins souple à l'usage que ce module...
La même chose pour Java ?
Quelqu'un connait un trucs similaire mais qui générerait une jsp pour afficher les formulaires et une servlet en Java pour le coté client ?
Pour l'instant je fais tout à la mano, et c'est vrai que c'est très très galère de faire quelque chose de propre qui remonte une info à l'utilisateur pour toutes les erreurs possibles.
-
[^]Re: La même chose pour Java ?
Posté par B r u n o (page perso, ) le 24/06/2004 à 08:22. (lien). Évalué à 2.Pour la validation il y a Validator de Jakarta Commons http://jakarta.apache.org/commons/validator/(...)
Aprés, pour une approche plus globale, tu devrais jeter un oeil sur des frameworks genre Struts [http://jakarta.apache.org/struts/(...)], WebWork [http://www.opensymphony.com/webwork/(...)], Tapestry [http://jakarta.apache.org/tapestry/index.html(...)] ou plus orienté UI : Millestone [http://millstone.org/(...)], Iternum [http://www.iternum.com/ui-demo/demos.jsp(...)]
-
[^]Re: La même chose pour Java ?
Posté par Lastnico Nicolas Ternisien (page perso, ) le 24/06/2004 à 08:33. (lien). Évalué à 2.C'est justement un projet que je fait actuellement dans mon stage, donc si cela t'intéresse dans 2 mois, je pourrait involontairement te donner les sources, que je pourrais meme d'ailleurs mettre en gpl si il se retrouve etre utile...
--
http://www.forum-software.org
Trouvez le meilleur logiciel de forum Internet pour votre communauté !
Manque une interface graphique
J'ai pas trop compris, mais j'ai l'impression que c'est un des éléments qui manque pour faire quelque chose qui rend des services identiques à MS-ACCESS.
En gros, l'intérêt de MS-ACCESS est que l'on peut construire le formulaire à grand coup de souris, il génère toute la sauce qui va autour. FORMSESS semble faire la sauce, il manque l'interface graphique.
Cette page a été générée par Templeet en 0.1116s (dont 0.0328 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
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.