par
Hywan » 08 juil. 2009, 13:29
@Dunbar : Je développe oui.
Validation : l'utilisateur saisie et envoie une donnée. On a associé un ou plusieurs validateurs (chaînage, pile etc.) sur un champ. Il est capable de nous dire s'il est valide ou pas. Bien sûr, on a des erreurs à gérer. Et donc des traductions d'erreurs.
Filtrage : opération à effectuer avant la validation. Les données envoyées sont passées dans un ou plusieurs filtres (chaînage, pile etc.). La donnée finale est envoyée au(x) validateur(s).
Persistence des données : l'utilisateur envoie les données, mais une erreur reste dans la saisie. Chance, les autres champs ont conservé les précédentes saisies : l'utilisateur n'a pas à tout retaper.
L'enregistrement : faire des ponts avec des bases de données, des XML, des mails, des trucs et des machins. Bref, prévoir une sorte de sortie standard exploitable par tout le monde pour que tout le monde puisse se brancher sur la sortie. Donc ça implique un parcours récursif simplifié à l'extrême du formulaire (une sorte de foreach($form) qui permet de tout récupérer sans se soucier de l'élément interroger).
L'affichage du formulaire : sortie XML, PDF, HTML, YAML, INI ... ? Il faut avoir des couches distinctes : une pour le traitement (validateur et filtre), une pour le formulaire, et une pour l'affichage. Voir le
design pattern décorateur par exemple. On peut aussi s'amuser avec un visiteur, c'est comme on veut.
Sérialisation des formulaires : on veut éditer le formulaire depuis un interface administrateur. Donc le formulaire ne doit pas être écrit en PHP, mais en XML par exemple, ou YAML, INI, JSON, Array etc. Il faut pouvoir passer de n'importe quel format de sérialisation vers un code PHP facilement. L'idée est de tout transformer en tableau PHP. Donc avoir des formats correctement définis et simples.
La seule interaction possible avec l'utilisateur s'effectue par le biais des formulaires. Autant dire qu'on en écrit beaucoup. Ça doit être
la partie qui doit être simplifiée à l'extrême. Sans oublier que chaque formulaire à sa touche personnelle, on a jamais deux fois le même. Donc souplesse : formulaire partielle et/ou enrichissement de formulaires possibles si ce sont des objets (j'ai un formulaire B qui hérite d'un formulaire A, je lui ajoute des champs et modifies quelques validateurs, le tout en 4 lignes de code).
Bref. Ce n'est pas si simple et c'est un point central. Le but serait de pouvoir créer ses formulaires par une interface graphique et de lier des actions à chaque champ. C'est possible si c'est bien conçu. Je sais qu'avec mon outil, je crée un formulaire en 5mn : l'affichage, le filtrage, la validation et la gestion des erreurs et déjà pris en compte, tout comme la persistence des données. L'enregistrement se fait à travers un pont manuel pour l'instant, mais ça me prend 3 lignes de code pour l'écrire (merci PDO et ses lieurs de variables).
C'est un bon exercice de POO remarque
.
@Dunbar : Je développe oui.
Validation : l'utilisateur saisie et envoie une donnée. On a associé un ou plusieurs validateurs (chaînage, pile etc.) sur un champ. Il est capable de nous dire s'il est valide ou pas. Bien sûr, on a des erreurs à gérer. Et donc des traductions d'erreurs.
Filtrage : opération à effectuer avant la validation. Les données envoyées sont passées dans un ou plusieurs filtres (chaînage, pile etc.). La donnée finale est envoyée au(x) validateur(s).
Persistence des données : l'utilisateur envoie les données, mais une erreur reste dans la saisie. Chance, les autres champs ont conservé les précédentes saisies : l'utilisateur n'a pas à tout retaper.
L'enregistrement : faire des ponts avec des bases de données, des XML, des mails, des trucs et des machins. Bref, prévoir une sorte de sortie standard exploitable par tout le monde pour que tout le monde puisse se brancher sur la sortie. Donc ça implique un parcours récursif simplifié à l'extrême du formulaire (une sorte de foreach($form) qui permet de tout récupérer sans se soucier de l'élément interroger).
L'affichage du formulaire : sortie XML, PDF, HTML, YAML, INI ... ? Il faut avoir des couches distinctes : une pour le traitement (validateur et filtre), une pour le formulaire, et une pour l'affichage. Voir le [i]design pattern[/i] décorateur par exemple. On peut aussi s'amuser avec un visiteur, c'est comme on veut.
Sérialisation des formulaires : on veut éditer le formulaire depuis un interface administrateur. Donc le formulaire ne doit pas être écrit en PHP, mais en XML par exemple, ou YAML, INI, JSON, Array etc. Il faut pouvoir passer de n'importe quel format de sérialisation vers un code PHP facilement. L'idée est de tout transformer en tableau PHP. Donc avoir des formats correctement définis et simples.
La seule interaction possible avec l'utilisateur s'effectue par le biais des formulaires. Autant dire qu'on en écrit beaucoup. Ça doit être [b]la[/b] partie qui doit être simplifiée à l'extrême. Sans oublier que chaque formulaire à sa touche personnelle, on a jamais deux fois le même. Donc souplesse : formulaire partielle et/ou enrichissement de formulaires possibles si ce sont des objets (j'ai un formulaire B qui hérite d'un formulaire A, je lui ajoute des champs et modifies quelques validateurs, le tout en 4 lignes de code).
Bref. Ce n'est pas si simple et c'est un point central. Le but serait de pouvoir créer ses formulaires par une interface graphique et de lier des actions à chaque champ. C'est possible si c'est bien conçu. Je sais qu'avec mon outil, je crée un formulaire en 5mn : l'affichage, le filtrage, la validation et la gestion des erreurs et déjà pris en compte, tout comme la persistence des données. L'enregistrement se fait à travers un pont manuel pour l'instant, mais ça me prend 3 lignes de code pour l'écrire (merci PDO et ses lieurs de variables).
C'est un bon exercice de POO remarque :-).
