Bonjour,

Depuis quelques temps maintenant, j'ai développé un utilitaire de création de formulaires avec PHP. Dans un premier temps, je l'ai fait afin de mieux saisir le concept d'objets. Désormais, il est fonctionnel et me fait gagner beaucoup de temps lors de mes développements.

Actuellement, il a été testé plusieurs fois par un ami (Maximilien Debrus), et fonctionne sur les plates formes testées (windows, linux).

Je souhaitais donc le faire partager à ceux qui voulaient l'utiliser, sans restriction (à moins qu'ils veuillent également contribuer, créer des extensions, me donner des astuces pour améliorer ...).

Actuellement, les FormTools proposent de construire un formulaire avec PHP, en effectuant le contrôle d'erreurs en PHP. A terme, j'y inclurai les contrôles en javascript.

Le lien :

http://www.mathieu-corgnet.fr/formTools/index.php5

La doc :

http://www.mathieu-corgnet.fr/formTools/doc

Merci à vous.

Salut!

Je viens de regarder tes différents codes source pour la mise en place de formulaires. L'idée est géniale !
En fait, il faut bien reconnaître que faire des formulaires c'est complètement fastidueux, on fait toujours des tas d'erreurs et on oublie des tests sur les entrées utilisateurs.
Pour ce qui est de ton outils, j'ai regardé attentivement les codes exemples que tu donne, et la première critique qui me viens à l'esprit, c'est le volume ! Il y a énormément de code à taper !
Par exemple, pour le premier champs, un 'text in', on à ça :

/**
* CREE UN OBJET TEXTIN
* <input type="text">
*/
$nom = new TextIn("nom", "nom");
// Définit le label du champ
$nom->SetLabel("* Nom : ");
// Définit le contenu de l'attribut Alt
$nom->SetAlt("Tapez votre nom en majuscules");
// Définit le nombre maximal de caractères pour ce champ
$nom->SetMaxLength(20);
// Définit le contenu de l'attribut Title
$nom->SetTitle("Saisissez votre nom de famille");
// Oblige l'utilisateur à inscrire une valeur dans le champ
$nom->NotEmpty();
$nom->SetValue("test");
// Fonction javascript lorsque le champ prend le focus
$nom->OnFocus("colorCell");
// Fonction javascript lorsque le champ perd le focus
$nom->OnBlur("unColorCell");
// Met le contenu du champ en majuscules
$nom->ToUpper(); 

Ce qui est complet mais vraiment lourd. Moi je différencierais bien les trois choses importantes d'un champs : sa définition (longueur, label, charset,..), les paramètres de validité, et ceux de l'affichage.
Pour la validité d'un champs, pourquoi ne pas utilser les masques par exemple :

$nom->SetValidCondition(NOT_EMPTY | NO_DIGIT | NO_SPACE);

c'est un exemple biensûr...
Pour l'affichage aussi, il y a sûrement moyen d'économiser du code redondant, par exemple en faisant un objet commun à tout le formulaire...

Pour le HTML, c'est pareil, trop de code.... Il n'est pas évident de garder un système aussi flexible, mais c'est sûrement possible en permettant de récupérer le formulaire en vrac dans un tableau, ou au contraire de paufiner l'affichage lors de la création du formulaire et de simplement faire un

$myForm->echoHTML();

. Le fait de récupérer les champs un par un est rebutant, d'autant qu'ils ont été défini un par un, ce qui double le travail ...

Points positifs, les fonctions disponibles rendent certaines tâches faciles, la gestion des erreurs est pas mal aussi


Voilà, l'idée reste bonne, j'espère que mes critiques sont constructives, @++ !

Raphaël Londeix

Il y a énormément de code à taper !

Dans mon exemple, il y a les commentaires plus toutes les options possibles pour un champ donné. De plus, en passant par le formulaire généré, qui est composé des champs, tu peux définir certaines fonctionnalités en bloc, et ça les mettra en place pour tous les champs.

$nom->SetValidCondition(NOT_EMPTY | NO_DIGIT | NO_SPACE);

Je vais étudier ça, mais je n'ai jamais pratiqué ... Comment ça fonctionne ?

$myForm->echoHTML();

Au pire, tu étends la classe FormTools, avec un affichage personnalisé. Pour le côté html, tu n'as que deux "echo" à faire, c'est extrèmement simple.

echo $champText->BuildLabel();
echo $chamText->BuildHtml();

et seulement un seul si tu ne veux pas le label

Merci beaucoup de ton intervention, je la prends en compte, et je teste si c'est faisable et si ça rentre dans ma logique.

Mathieu.

$nom->SetValidCondition(NOT_EMPTY | NO_DIGIT | NO_SPACE);

Je vais étudier ça, mais je n'ai jamais pratiqué ... Comment ça fonctionne ?

Je pensais à des masques binaires, par exemple
NOT_EMPTY = 2
NO_DIGIT = 4
NO_SPACE= 8
et ainsi de suite des puissances de 2.
Après pour savoir quels 'flags' sont présent, il te suffit de soustraire les puissances une à une, puisque chaque combinaison est unique. Par exemple,
NOT_EMPTY | NO_DIGIT = 6
tu enlèves les plus grandes d'abord:
* on peut pas enlever NO_SPACE à 6 => NO_SPACE est absent
* on peut enlever NO_DIGIT à 6 => NO_DIGIT présent
* on peut enlever NOT_EMPTY à 2 => NOT_EMPTY est présent
bref tu as compris, sinon masque binaire sur google

$myForm->echoHTML();

Au pire, tu étends la classe FormTools, avec un affichage personnalisé. Pour le côté html, tu n'as que deux "echo" à faire, c'est extrèmement simple.

echo $champText->BuildLabel();
echo $chamText->BuildHtml();

et seulement un seul si tu ne veux pas le label

Ben je parlais de remplacer toute la page HTML par un appel à une fonction comme echoHTML(). En fait, dans la conception de ta classe, le truc bancal, c'est que certains aspects graphiques sont présent dans la classe justement, et d'autres sont dans le html. Pourquoi ne pas faire tout d'un coup, et en profiter pour mieux dissocier ce qui est graphique du reste dans la construction des champs du formulaire?
Peut-être, comme tu le dis, une sur-couche permettrait d'obtenir ce résultat.. En tout cas, je serais le premier à utiliser ton outil s'il m'économise du code

++!

Pourrais-tu te placer par rapport à PEAR/QuickForm ?

Après pour savoir quels 'flags' sont présent, il te suffit de soustraire les puissances une à une, puisque chaque combinaison est unique. Par exemple,
NOT_EMPTY | NO_DIGIT = 6
tu enlèves les plus grandes d'abord:
* on peut pas enlever NO_SPACE à 6 => NO_SPACE est absent
* on peut enlever NO_DIGIT à 6 => NO_DIGIT présent
* on peut enlever NOT_EMPTY à 2 => NOT_EMPTY est présent

Non, pour tester on fait un et bit à bit :

if(NOT_EMPTY & mask) // mask contient NOT_EMPTY

bien vu

Je pensais à des masques binaires, par exemple
NOT_EMPTY = 2
NO_DIGIT = 4
NO_SPACE= 8
et ainsi de suite des puissances de 2.
Après pour savoir quels 'flags' sont présent, il te suffit de soustraire les puissances une à une, puisque chaque combinaison est unique. Par exemple,
NOT_EMPTY | NO_DIGIT = 6
tu enlèves les plus grandes d'abord:
* on peut pas enlever NO_SPACE à 6 => NO_SPACE est absent
* on peut enlever NO_DIGIT à 6 => NO_DIGIT présent
* on peut enlever NOT_EMPTY à 2 => NOT_EMPTY est présent
bref tu as compris, sinon masque binaire sur google

Je dois étudier cette solution, je ne l'ai jamais utilisée. Elle me paraît efficace, et sera une alternative à ce qui existe déjà.

Ben je parlais de remplacer toute la page HTML par un appel à une fonction comme echoHTML(). En fait, dans la conception de ta classe, le truc bancal, c'est que certains aspects graphiques sont présent dans la classe justement, et d'autres sont dans le html. Pourquoi ne pas faire tout d'un coup, et en profiter pour mieux dissocier ce qui est graphique du reste dans la construction des champs du formulaire?
Peut-être, comme tu le dis, une sur-couche permettrait d'obtenir ce résultat.. En tout cas, je serais le premier à utiliser ton outil s'il m'économise du code

Le but, pour moi, est de créer un utilitaire de construction de formulaires, évolutif et simple. Je veux permettre à l'utilisateur de placer les éléments comme il le veut, et je n'interviens que sur les balises de formulaires, avec un rendu en xhtml 1.0 strict.

Si le type veut faire un tableau pour placer ses éléments (ça peut arriver, et ça m'arrive), il utilise un tableau. S'il veut tout négocier en css, c'est possible aussi.

L'intérêt de ce package, c'est qu'il est indépendant de tout autre package, donc extrêmement portatif.

Je ne sais pas si je réponds bien à ta question, pour l'instant, je me limite aux formulaires, et n'agis pas sur la page de l'utilisateur.

Pour info, j'ai actuellement deux utilisateurs débutants en php (aucune notion d'objet), qui se sont appropriés les FormTools très rapidement, en me posant peu de questions. L'un d'eux construit un site avec leur aide, et tous ses formulaires passent correctement, avec contrôles de saisie etc ...

De plus, je fais des contrôles de sécurité "anti-piratage" (exemple : empêcher l'utilisateur de mettre une valeur non prévue dans un select, avec la méthode $select->TestOriginalList() );

Pourrais-tu te placer par rapport à PEAR/QuickForm ?

J'ai parcouru la doc de QuickForm, je ne connaissais pas. Pour info, à l'origine, les formtools faisaient partie d'un projet d'étude, et de mon envie d'apprendre plus sur la programmation orientée objets (très efficace, puisqu'utilisation d'héritages, et d'agrégations ...).

Bref, pour quickform, je n'ai pas aimé le système. Peu évolutif, à mon sens, il ne traite pas les champs de formulaire comme des objets.

De mon côté, je traite chaque champ comme un nouvel objet, ce qui a de gros côtés pratiques, notamment dans les cas de boutons radio et de champs texte :

Radio :
J'utilise deux classes : RadioInGroup représente un groupe de boutons radios, et est composé de boutons radios. En matière de validation, c'est très pratique, puisque l'appel à une seule méthode sur le groupe de boutons oblige l'utilisateur à en cocher au moins un. Un groupe de boutons radio devient un champ de formulaires.

Text :
TextIn est une classe (au début, c'était pour TextInput, finalement, j'ai mis le "in" à tous les champs de formulaire). Elle peut être étendue, et c'est tout son intérêt. Je prends l'exemple fourni sur pear/quickform à cette adresse :
http://php.developpez.com/cours/pear/ht ... UAAAAe17IF

Dans le cas d'un champ de login, vous créez la classe TextInLogin, elle étend la classe TextIn, il faut lui créer une méthode CheckLogin() et l'appeler à l'instance ou obliger l'utilisateur à la paramétrer, et ça devient un champ de formulaire à part entière.
Ca fera en plus une contribution ...

Pear/quickform a certainement plus de fonctionnalités, et est plus mature. L'outil que je propose n'apporte peut être rien du tout par rapport à pear, je n'en sais rien, et je préfère ne pas me poser la question. Utilisez le si vous en avez envie, modifiez le à souhait, je ne sais même pas si j'ai envie de le mettre sous licence.

J'espère avoir bien compris vos questions, et y avoir répondu.

Mathieu.

Bonjour à tous

Désolé pour ce message un peu HS, mais je me demandais si vous aviez par hasard un ou deux liens intéressants pour apprendre un peu plus sur les masques binaires, j'ai fait une recherche Google mais je ne tombe sur rien de vraiment concluant en français (et oui, mon anglais est une véritable catastrophe... )... bref, si vous aviez quelques pistes d'apprentissage sur ce sujet, je suis preneur !

Pour dire un mot sur le projet présenté ici, je le trouve fort intéressant, on passe parfois pas mal de temps à faire des formulaires, toute aide dans ce domaine est donc appréciable. Seul regret, que FormTools ne propose pas un système simple de modèles, un peu comme si on fournissait au script un simple gabarit avec les différents objets qu'on désire, sous forme de balises personnalisées, et que le programme les utilise pour générer le formulaire automatiquement... un peu dans cet esprit :

<div class="form">
[form:post:contact.php]
[text:nom:Votre nom]
[text:mel:Votre E-mail]
[text:sujet:Le sujet du message]
[area:message:]
[submit:send:Envoyer]
[/form]
</div>

Chaque objet du formulaire serait ainsi construit de manière très simple et rapide en indiquant juste le type d'objet, son nom et la valeur par défaut à utiliser... le programme n'aurais qu'à interpréter ce modèle puis retournerais un formulaire entier tout propre...

Enfin, ce n'est qu'une idée... le tout est de faciliter au maximum la création des petits formulaires, après on pourrait affiner et/ou compléter les attributs et comportements de chaque objet avec la méthode déjà existante... possible ou pas ?

Merci

Ca relève des compétences du template ...

Je les utilise d'un point de vue personnel, et rien ne t'empêche de les utiliser de ton côté, mais je crois que ça sort du cadre de mon développement, pour l'instant.

A ce jour, je travailler sur deux choses, au sujet des formtools :

- générer les prototypes javascript
- générer le code des formtools avec un fichier de définitions (pour une base de données, notamment)

J'en profite pour te demander comment tu peux faire pour générer dynamiquement tout ça ... Je n'ai aucune idée du comment faire, mais ça peut m'intéresser professionnellement. Techniquement, comment on fait ?

Re...

Ca relève des compétences du template ...

En effet... c'est vrai qu'on pourrait mettre ça en place sans que FormTools ne le propose de manière native... je vais creuser un peu la question dès que j'aurais un peu plus de disponibilité...

J'en profite pour te demander comment tu peux faire pour générer dynamiquement tout ça ... Je n'ai aucune idée du comment faire, mais ça peut m'intéresser professionnellement. Techniquement, comment on fait ?

Heu... j'ai un peu de mal à comprendre sur quoi exactement porte ta question : sur l'histoire des templates ? ... ou sur les prototypes JS et les fichiers de définitions ?

Disons que, dans les deux cas, je serai bien en mal de te venir à l'aide, mes compétences en développement sont assez modestes et mon expérience ne se porte pour l'instant que sur la réalisation de quelques projets bien insignifiants par rapport à ceux que d'autres proposent dans ces colonnes (comme le tiens d'ailleurs)... bref, je ne suis qu'un simple développeur du dimanche, et ne prétends pas arriver un jour à votre niveau (ou par accident alors )

Mais bon, je suis certains projets car je les trouve fort intéressants et utiles, et ne désespère pas de pouvoir un jour proposer des réalisations aussi abouties que les vôtres... enfin, j'espère

à+

J'en profite pour te demander comment tu peux faire pour générer dynamiquement tout ça ... Je n'ai aucune idée du comment faire, mais ça peut m'intéresser professionnellement. Techniquement, comment on fait ?

Arf ... j'ai copié ça là sans le vouloir en fait, c'était destiné à un autre forum

Toutes mes excuses (hooonteux)

Re...

Arf ... j'ai copié ça là sans le vouloir en fait, c'était destiné à un autre forum

Haaa... d'accord... je me disais aussi que ta question était un peu zarbi dans ce contexte... tout s'explique

à+

<div class="form">
[form:post:contact.php]
[text:nom:Votre nom]
[text:mel:Votre E-mail]
[text:sujet:Le sujet du message]
[area:message:]
[submit:send:Envoyer]
[/form]
</div>

C'est marrant, j'avais fait un truc pour des templates qui ressemblaient à ça :

<form(post,action.php)>
<fieldset(Informations générales) />
<input(nom,Votre nom) />
<password(pass,Le mot de passe) />
</fieldset>
<submit(Envoyer !) />
</form>

Le seul problème est que je ne générais pas le formulaire qui allait avec... :-°
Ca me donne envie de m'y remettre. ^^


En fait mon idée était beaucoup plus poussée et devait permettre à partir d'une table SQL de faire tout le nécessaire à l'affichage, l'ajout, la modification et la suppression d'éléments via des "wrappers" de types. Il suffirait de dire le label du champ et quel wrapper utiliser ça serait bon. =) Par exemple le wrapper "password" s'occuperait de demander l'ancien pass + 2 fois le nouveau lors de la modification... Un wrapper pour les dates pourrait s'occuper d'afficher un calendrier javascript pour choisrir, etc.
Faut vraiment que je le fasse car l'idée est bien claire dans ma tête...[/url]

C'est quelque chose que j'avais déjà fait, en une seule classe. Pas très compliqué, en réalité, il me semble même que j'avais filé le code (dégueulasse) à cyrano.

Au final, ça s'est révélé trop peu paramétrable, et j'ai peu utilisé. C'étaient mes débuts en php.