JeuWeb - Crée ton jeu par navigateur
Petit ensemble de classes - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Petit ensemble de classes (/showthread.php?tid=3217)

Pages : 1 2 3


Petit ensemble de classes - Ekilio - 28-10-2008

Françaises, français, belges, belges, canadienne, canadiens, monsieur le président, mon chien, monsieur l'avocat le plus bas d'inter, public chéri mon amour !

Voici l'heure de la minute nécessaire de monsieur Ekilio. (Comprenne qui pourra ces deux phrases...)

Donc, ces derniers jours, ma petite occupation n'a pas été de trucider des lapins ou de générer des formes de vies étranges dans mon évier, mais bien de créer un ensemble de classes, que j'ai pompeusement regroupées sous le nom de framework, et que je m'en viens vous proposer ici.

Ce petit ensemble est basé sur ma vision du concept MVC (donc probablement un peu éloignée du principe d'origine), et a principalement pour but d'aider à créer rapidement les bases d'un site. Il utilise énormément le concept d'objet et d'héritage, donc PHP5 obligatoire.

Quelques petites explications sur les classes que contient ce framework et son fonctionnement :

- Les classes sont toutes rangées dans le répertoire "modules" du framework. Inutile une fois qu'une classe est créée de l'ajouter où que ce soit, les classes sont incluses si elles sont utiles.
- Les fichiers du répertoire "modules" doivent avoir pour nom le nom exact de la classe qu'ils contiennent.
- Les classes de base du framework sont :
  • configuration qui gère les objets du même nom ; elle sert à lire et écrire à la volée des configurations. J'y reviendrais un peu plus tard.
  • database est la classe d'accès à la base de données. Elle gère uniquement mysql, et utilise une syntaxe singleton. J'y reviendrais aussi en détails.
  • erreur est une classe statique qui sert à générer des erreurs et à les écrire dans un fichier de logs. Elle est principalement utilisée par database, mais vous pouvez bien sûr l'utiliser aussi dans votre application.
  • filtrage est une classe statique qui contient des méthodes de filtrage de formulaire spéciales et que vous souhaitez appliquer à vos champs. J'y reviendrais en parlant des formulaires.
  • formulaire est une classe de traitement des formulaires. Elle permet, via un fichier de configuration en php, de générer des formulaires, et de les traiter directement.
  • langue permet de gérer l'interface multi-langue. J'y reviendrais (encore).
  • module est une classe abstraite qui sert de base à (presque) toutes les classes que vous développez pour le framework. C'est l'une des classes les plus importante (formulaire en hérite, entre autres).
  • utilisateur est une classe qui sert à gérer les actions de base de l'utilisateur. Elle est prévue pour être héritée.

Détaillons un peu...

Configuration et langue

Ces deux classes s'utilisent plus ou moins de la même façons, donc je les regroupent. Elles sont principalement chargée par les modules (c'est une des actions par défaut du constructeur de la classe module) mais vous pouvez bien sûr vous en servir de la manière que vous souhaitez.

Configuration

Cette classe se charge en indiquant en paramètre le nom du fichier de configuration à charger. Les fichiers de configuration se trouvent dans le dossier configs (qui est protégé par un .htaccess) ; il faut donner à la classe le droit d'écrire dans ce dossier (chmod).

Lorsque vous créez un fichier de configuration, il suffit de le mettre sous forme d'un tableau associatif nommé $configurationC dans le fichier, où chaque clef est une des clefs de la configuration et chaque valeur la valeur de cette clef. Le système transformera automatiquement ce fichier en un fichier mconf.

Pour utiliser la classe, il suffit donc de la charger :

Code PHP :
<?php 
$configuration
= new configuration('monfichier');

N'indiquez bien sûr pas d'extension dans le paramètre. Ensuite, vous pouvez lire ou écrire des valeurs de configuration de cette façon :

Code PHP :
<?php 
$maValeur
= $configuration->maValeur;
$configuration->maValeur = 3

La configuration se sauvegarde automatiquement, il n'est pas nécessaire de le faire.

Langue

La classe de langue s'utilise d'une manière sensiblement identique à la classe de configuration. Avec néanmoins quelques petites différences.

Tout d'abord, les fichiers de langue sont stockés dans des répertoires nommé par le code de la langue (fr pour le français, par exemple). Ces répertoires doivent être dans le dossier "langues", qui est protégé par un .htaccess.

La langue à utiliser est déterminée de deux façons : si il existe une valeur "langue" chez l'utilisateur, alors c'est celle-ci qui sera utilisée. Sinon, c'est la clef defautLangue de la configuration global qui sera utilisée.

Contrairement à la classe configuration, la classe langue implémente Iterrator : il est donc possible d'en parcourir toutes les valeures :

Code PHP :
<?php 
foreach($langue as $clef => $valeur)
{
}

Database

La classe database est une interface d'accès à la base de données. Elle se base sur une syntaxe singleton : il est donc impossible de faire :

Code PHP :
<?php 
$db
= new database();

Cela vous retournera une erreur. A la place, utilisez toujours :

Code PHP :
<?php 
$db
= database::create();

De part la syntaxe singleton, la classe n'est jamais créée plusieurs fois ; du coup, vous pouvez sans problèmes faire un appel à cette fonction statique dans plusieurs fonctions, et ce sera moins lourd que de garder votre classe dans une variable de votre module.

La classe database contient les fonctions suivantes :

- query prends en paramètre une requête SQL. Elle l'execute, et renvoi son résultat si la requête en retournait un.
Le résultat est toujours présenté sous forme d'un tableau de tableaux : chaque élément du premier niveau de tableaux est une ligne de résultat, le second niveau contenant les champs de cette ligne.
- free sert à libérer le dernier résultat. Utile pour gagner en performances. Cette fonction est appellée automatiquement à chaque requête, pour éviter de polluer la mémoire.
- num renvoi le nombre de lignes de la dernière requête effectuée.
- affected renvoi le nombre de champs affectés par la dernière requête effectuée.
- insertId renvoi l'id généré par le champs auto_increment de la dernière requête effectuée.
- update sert à mettre à jour tout une table (par exemple, toutes les informations sur votre utilisateur d'un seul coup). Son premier paramètre doit être un tableau associatif associant les noms des champs MySQL à la valeur que vous souhaitez leur donner. Le second paramètre doit être le nom du champs que vous utiliserez comme clef (et qui sera utilisé dans la clause WHERE). Le dernier paramètre est le nom de la table.

La classe erreur

Pendant de la classe database, la classe erreur sert à enregistrer les erreurs rencontrées pendant l'execution du script. C'est une classe statique, ce qui implique que vous n'avez jamais à l'instancier.

La seule méthode de la classe erreur est la méthode trigger ; celle-ci attends un certain nombre de paramètres :

- type doit être une des trois constantes de classe : TYPE_SQL, TYPE_PHP et TYPE_HAC. Cela va déterminer le fichier de log où la classe va enregistrer les erreurs.
- act indique l'action à effectuer. Il doit s'agir d'une des deux constantes de la classe, FATALE ou IGNORE. Dans le cas d'une erreur FATALE, le script s'arrêtera. Notez que si le tableau de configuration de la classe indique que le mode debug est activé, la classe s'arrêtera de toutes manières sur toutes les erreurs.
- err est le texte de l'erreur.
- system est un message système pour mieux comprendre l'erreur. Dans le cas d'une erreur mysql, c'est le résultat de la fonction mysql_error qui est indiqué ici. Ce paramètre est facultatif.
- requete est la requête ayant généré l'erreur. Dans le cas d'une erreur MySQL, c'est bien sûr la requête SQL. Ce paramètre est facultatif.

Les erreurs sont enregistrées sous la forme d'un tableau nommé $log, il suffit d'inclure le fichier voulu pour le récupérer. Ce tableau associatif associe chacun des champs ci-dessus avec sa valeur.

Utilisateur

La classe Utilisateur sert à gérer un... utilisateur Smile C'est elle qui gère la connexion, les informations de l'utilisateur, et la déconnexion.

Comme toutes les classes, elle est extensibles : il est prévu et même souhaité que vous l'utilisiez pour créer vos propres classes d'utilisateur, afin qu'elles soient parfaitement adaptées à vos besoins ! Cela dit, elle est aussi utilisable telle quel.

Par défaut, voici la liste de ses méthodes :

- connect_user sert à connecter un utilisateur en récupérant directement les données dans la variable $_POST. Notez qu'il n'y a aucun protection des variables ici, c'est tout à fait volontaire, la protection doit se faire avant via la classe formulaire. Cette fonction est la seule à utiliser un _ dans son nom, et ceci pour éviter qu'elle ne puisse être appellée directement, ce qui présenterais une faille de sécurité.

- protegePseudo sert simplement à enlever les apostrophes d'un pseudonyme et à mettre en forme les caractères HTML.

- administrateur renvoi true si l'utilisateur est administrateur. Cette fonction est bien sûr prévue pour être étendue.

- moderateur renvoi true si l'utilisateur est administrateur ou modérateur. Cette fonction est aussi prévue pour être étendue.

- deconnexion déconnecte l'utilisateur.

A noter que l'objet utilisateur est stoqué dans la session, et vous pouvez donc faire appel à toutes ses fonctions de cette manière :

Code PHP :
<?php 
if($_SESSION['utilisateur']->administrateur())
{
echo
'Bonjour grand chef';
}

De plus, la classe utilisateur contient un tableau protégé nommé userInfos, qui contient toutes les informations relatives à l'utilisateur.

Ces informations sont accessible directement, de cette manière :

Code PHP :
<?php 
echo $_SESSION['utilisateur']->login;

Module

Bien, on rentre maintenant dans l'une des deux classes les plus importantes. Module est une classe abstraite qui sert à donner un modèle pour les différents modules de votre application.

Cette classe ne peut jamais être appellée directement, il faut obligatoirement l'hériter dans une autre classe. La plupart de ses fonctions en revanche n'ont pas besoin d'être surchargées (même si c'est bien sûr toujours possible), une fois qu'une classe hérite de module, il n'y a plus qu'à définir ses actions et le reste se fera tout seul.

A noter que toute classe qui hérite de module dispose automatiquement d'une configuration et d'une langue, qui seront créées si elles n'existent pas. Elle sont accessible respectivement par $this->configuration et $this->langueModule

Parmis les variables de classes, il y en a deux importantes :

- nomModule est une variable qui doit être déclarée dans tous les modules héritant de cette classe, et qui doit contenir le nom du module. Cela doit être fait de cette manière :

Code PHP :
<?php 
protected $nomModule = 'monModule';

Cette variable est utilisée pour récupérer les vues, pour récupérer la configuration et les variables de langue.

- nomVue est la variable qui doit contenir le nom de la vue en cours.

Le principe des modules est le suivant : la classe héritée est créée. Par défaut, cela charge la configuration et la langue (action du constructeur de module). Ensuite, une fonction est appellée dans cette classe, laquelle fonction est l'action demandée par l'utilisateur. Cette fonction est la seule chose réellement obligatoire à coder dans un module.

Dans cette fonction, il faut au moins définir le nom de la vue à afficher. Ce nom doit correspondre à un fichier html dans le dossier vues, sachant que le nom est préfixé par le nom du module et _. Ainsi, par exemple, la vue pour le module "bonjour" nommée "accueil" sera le fichier bonjour_accueil.html.

Une vue est donc un fichier html normal, à ceci près qu'elle peut contenir deux choses :

- Des clefs de la forme {CLEF} (la clef doit toujours être en majuscule)
- Des tests de la forme <!-- TEST NOMDEMONTEST --><!-- FINTEST NOMDEMONTEST --> (ici aussi, le nom du test doit toujours être en majuscule).

On peut aussi définir deux autres tableaux dans la fonction :

- parserArray est un tableau associatif. Chaque clef du tableau doit être une clef présente dans la vue. La clef dans la vue sera alors remplacée par la valeur présente dans le tableau. A noter qu'il n'est pas nécessaire que les clefs respectent la casse ici et qu'elle ne doivent pas avoir leurs {}. Ainsi :

Code PHP :
<?php 
$this
->parserArray['clef'] = 'Bonjour';

Remplacera dans la vue toutes les occurences de {CLEF} par Bonjour.

- masquesArray est un tableau simple. Chaque élément de ce tableau doit être le nom d'un test. Tous les tests présents dans ce tableau seront masqués. Par exemple, avec cette vue :

Code PHP :
<?php 
Bonjour
<!-- TEST ESTADMINISTRATEUR -->monsieur l'administrateur<!-- FINTEST ESTADMINISTRATEUR -->

Et ce code :

Code PHP :
<?php 
$this
->masquesArray[] = 'estAdministrateur';

On aura pour affichage :

Citation :Bonjour

Notez que le nom des tests dans le code PHP n'est pas non plus sensible à la casse.

Un fois tout ceci défini, il ne reste plus qu'à laisser faire le module. Les fonctions suivantes seront alors appellées (toutes sont extensibles) :

- parserVue va appeller toutes les fonctions à venir (sauf vue()).

- chargerVue va récupérer le code html dans le fichier de la vue et le stoquer dans la variable protégée $this->vue

- A ce niveau, parserVue reprends la main en replaçant toutes les clefs contenues dans le tableau parserArray

- Puis parserVue va appeller la fonction masquerTest pour masquer l'un après l'autre tous les tests contenus dans le tableau masquesArray. La fonction masquerTest ne prends qu'un seul paramètre, le nom du test à masquer.

- Enfin, la fonction parserVue va appeller la fonction parserLangue qui va remplacer toutes les clefs de langue définies pour ce module par leurs valeures. De ce fait, il faut bien faire attention à ne jamais donner à une clef une valeur déjà définie comme une clef de langue (l'idéal étant par exemple de nommer les clefs de langue {L_CLEF}). Le but avoué de ceci est de permettre une gestion transparente du multi-langue, la clef de langue affiché étant toujours dans la langue de l'utilisateur.

- Ensuite, la fonction parserVue se termine, et le framework va appeller la fonction vue, qui par défaut lui retourne simplement le contenu de la variable $this->vue.

Toutes ces fonctions sont bien sûr prévues pour être étendues.

Voici un exemple de module très simple :

Code PHP :
<?php

class defautIndex extends module
{
protected
$nomModule = 'defautIndex';

public function
index()
{
$this->nomVue = 'index';
}
}
?>

La vue defautIndex_index pourra contenir des variables de langue, qui seront remplacées directement, sans que vous n'ayez à le programmer.

Formulaire

Cette classe est celle que je met le plus souvent à jour. A l'heure où j'écris ces lignes, il y a une mise à jour de disponible, je suis juste en train de la tester. Je la mettrais en ligne dès que possible, d'autant plus qu'elle corrige une importante faille de sécurité. Ce sera probablement là demain, en attendant, il est fortement déconseillé d'utiliser cette classe dans un environnement réel (bien sûr, pas de problèmes pour les tests).

Le but de cette classe est de fournir un outil pratique et simple pour créer et gérer des formulaires. Cette classe part d'un tableau associatif et génère le formulaire, puis le traite dans certains cas.

La classe formulaire étends la classe module. Voici les fonctions propres à la classe :

- Le constructeur de classe peut attendre un paramètre qui est le nom du formulaire à charger. Si aucun paramètre n'est fourni (ce qui est principalement le cas lorsque l'utilisateur vient de valider un formulaire), elle charge le formulaire en cours (le fonctionnement de cette partie est légerement modifié avec la mise à jour à venir, pour le sécuriser).

- La fonction parserFormulaire est utilisée pour charger un formulaire. Normalement, vous n'avez pas besoin de la modifier.

- La fonction voirFormulaire renvoi le code html du formulaire chargé. Attention, cette fonction ne l'affiche pas, ça le renvoi juste.

- La fonction traiterFormulaire est appellée comme action pour les formulaires générés par la classe. C'est elle qui va gérer les formulaires, sécuriser les champs et les traiter.

- La fonction parserVue sert juste à éviter quelques petites choses de la part de la classe module.

Je ne détaille pas beaucoup plus ces fonctions, voici simplement comme les utiliser :

Code PHP :
<?php 
public function monAction()
{
$this->nomVue = 'maVueAvecUnFormulaire';
$formulaire = new formulaire('monFormulaire');
$this->parserArray['formulaire'] = $formulaire->voirFormulaire();
}

Et voila. La clef {FORMULAIRE} de votre vue est remplacée par le formulaire monFormulaire, et il sera traité.

Maintenant, je vais détailler un peu. Les formulaires sont des fichiers php présents dans le dossier formulaires. Chaque fichier php doit contenir un tableau nommé $formulaireInfos. Ce tableau est, bien sûr, un tableau associatif.

Voici la liste des clefs possibles au premier niveau de ce tableau. Je précise que certaines de ces clefs sont facultatives : ne pas les indiquer aura pour effet de désactiver la fonction correspondante. Les clefs facultatives seront indiquées en italique.
  • origine sert à spécifier l'origine du formulaire. Le principe est que la classe peut charger un formulaire directement de la base de données (origine DB) ou depuis le tableau (origine Array). Lorsque le formulaire est chargé depuis la base de données, il n'est pas nécessaire de détailler tous les champs, les champs que vous n'indiquerez pas seront simplement ajoutés par le système.
  • titre sert à donner un titre à votre formulaire. Ce titre sera utilisé comme légende du fieldset correspondant.
  • valider est le texte du bouton valider. Dans les fait, c'est facultatif, mais bon...
  • raz sert à remettre à zéro le formulaire (bouton de type reset). Si vous n'indiquez pas ce champs, il n'y aura pas de bouton.
  • action sert à préciser l'action du formulaire et ce qui se passera ensuite. C'est un tableau associatif qui attends les clefs suivantes :
    • type doit indiquer quoi faire avec les données. Les valeurs possibles sont no pour ne pas traiter les données (par exemple pour passer directement à un autre formulaire, si vous sélectionnez un utilisateur à modifier puis que vous affichez le formulaire de modification), fonction pour indiquer une fonction à executer dans un module précis, insert pour insérer les données dans une table, update pour mettre à jour les données d'une table, delete pour supprimer les données d'une table. Notez que les formulaires d'origine DB doivent avoir comme type d'action insert, update ou delete.
    • cible doit indiquer la cible de l'action. Ceci est inutile si le type est no. Si le type est à fonction, ce champs doit indiquer le module et le nom de l'action de se module, sous la forme module.action. Par exemple, pour connecter un utilisateur (module utilisateur, fonction connect_user), on doit mettre utilisateur.connect_user. A noter qu'aucune valeur n'est passée en paramètre à cette fonction, c'est à elle de récupérer les valeures du tableau $_POST (qui auront au préalable été protégées par la classe). Enfin, si le formulaire a pour action une table d'une base, la cible doit être le nom de cette table.
    • where indique une clause à utiliser dans le cadre des formulaires dont l'action est update ou delete. Deux possibilités ici : si vous indiquez simplement un champ présent dans le formulaire (par exemple, id), alors ce sera la valeur de ce champs qui sera utilisé au traitement. Mais ceci n'est pas valable dans le cas de formulaire chargés de la base (origine DB) : il faut alors spécifier une clause WHERE complète ('id = ' . intval($_POST['id'])). Pour des raisons de sécurité, il est vivement recommandé de protéger cette clause, comme dans mon exemple, car la protection liée au système interviendra après le chargement et le traitement de cette clause.
    • vue doit indiquer le nom de la vue à afficher ensuite. A noter que les noms de vue de formulaire doivent être précédés d'un _ : par exemple, si vous indiquez "commun_connexion" comme nom de vue, alors le fichier sera _commun_connexion.html. Ce paramètre est facultatif, mais si il n'est pas renseigné, le paramètre fvue doit l'être.
    • fvue indique une fonction a executer. Si ce paramètre est rempli, lorsque le formulaire aura été traité, le système appellera la fonction comme si il s'agissait d'un affichage, et l'affichera directement. La fonction doit être indiquée de la même manière que pour la cible des formulaires dont l'action est de type fonction.


    Pour des raisons de commodité (pour moi), le framework, sa documentation et son téléchargement sont en cours de déplacement vers mon nouveau blog.

    Le lien pour télécharger le framework est donc devenu celui-ci :

    http://www.ames-troubles.com/post/Mon-propre-framework



RE: Petit ensemble de classes - Plume - 28-10-2008

Viens t'en participer à scratch : http://plumeconception.olympe-network.com/wiki/doku.php?id=scratch:scratch Hm ?
J'parle pour l'instant à la première personne mais j'invite également toute personnes à participer :]

So, si t'es intéressé pour partager et t'investir, les portes sont grandes ouvertes :] L'idée principale étant de concevoir un fw au plus proche possible adapté à la réalisation de jeu webbased. L'idée était lancée par Sephi dans un fil : http://www.jeuweb.org/board/showthread.php?tid=4489

J'ai décidé de prendre le flambeau. Maintenant, c'est évidemment un projet ouvert donc libre à chacun de fournir sa pierre.

Alors ?


RE: Petit ensemble de classes - Ekilio - 28-10-2008

Ben, le truc c'est que cet outil-ci, je l'utilise pour mon boulot, donc je peux le modifier et le maintenir facilement ^^" Je n'ai pas beaucoup de temps hors de mon boulot pour coder, entre Aluren et les jeux auquels je joue ^^"

Mais si tu veux utiliser des classes de ceci (éventuellement modifiées), n'hésites surtout pas :-) Je vais finir la documentation.


RE: Petit ensemble de classes - Plume - 29-10-2008

Niquel, j'regarderais ça en détail :] J'ai pas le boulot pour coder moi Big Grin

@tchaOo°


RE: Petit ensemble de classes - Plume - 29-10-2008

J'vais me permettre quelques transformations.
  • Tous les commentaires en anglais ( peut être les laisser en français à côté )
  • Mettre des commentaires quand ils sont absents
  • Adoption de la syntaxe PHPDoc
  • Nom de variables, constantes, fonctions en anglais. No need mélanger de manière étrange l'anglais et le français
  • Renommer les classes, j'suis un peu maniaque et j'aime bien voir les classes avec une majuscule
  • Tenir à jour la documentation
  • La compléter

Si tu fais des modifs de classes ou autres, fais moi signe surtout dans le cas d'un bug, d'une faille ou autre chose du même genre critique :]

Les classes sous une licence particulière ?

Merci Wink

@tchaOo°


RE: Petit ensemble de classes - Ekilio - 31-10-2008

Salut,

Désolé du temps de réponse, beaucoup de boulot en ce moment (d'ailleurs je poste du boulot, bouuuh).

Donc, j'ai fait un certain nombre de modifications pour régler plusieurs bugs et augmenter nettement les possibilités (particulièrement pour la classe formulaire). J'en ferais une version tout en anglais si tu veux (probablement pendant le week-end), par contre pour le phpdoc j'ai peur de ne pas avoir le temps. Et je posterais le tout ici.

J'en profiterais pour completer la documentation. Particulièrement pour les classes formulaire et module, qui sont les deux plus importantes ^^"

Pour la licence, j'ai pas défini encore précisement, mais ce sera du libre, probablement GPL.


RE: Petit ensemble de classes - Ekilio - 04-11-2008

La doc a été mise à jour, et le script aussi. Attention, comme indiqué dans la doc, il me reste une mise à jour à faire, NE PAS UTILISER LE SCRIPT TEL QU'IL EST ACTUELLEMENT SUR UN ENVIRONNEMENT LIVE, ou plus exactement la classe formulaire, qui contient une faille de sécurité assez grave. J'ai la rectification, mais elle est à mon boulot et je ne bosse pas aujourd'hui ^^" Donc je mettrais à jour demain.

Je finirais par contre la mise à jour de la documentation dans la journée ; et lorsque je ferais la mise à jour de demain, je passerais tout en anglais, comme tu l'as demandé Smile Sauf les commentaires, je n'aurais pas le temps.


RE: Petit ensemble de classes - Plume - 04-11-2008

Je ferais ça =)

Par contre, je me pose la question de la nécessité de générer les formulaires =/


RE: Petit ensemble de classes - Ekilio - 04-11-2008

Ce n'est jamais obligatoire d'utiliser les classes ^^ mais là les formulaires je dois avouer qu'ils sont très très pratique, pour moi du moins...

En fait, le truc est que avec ces classes, en deux minutes tu as par exemple un formulaire de création d'utilisateur sécurisé et qui se gère tout seul, idem pour un formulaire d'administration des utilisateurs, des actions, etc... Ca permet d'accélérer énormément les formulaires. Après, bien sûr, on reste libre de créer ses formulaires à la main dans les vues, mais disons que pour plein de choses, particulièrement les longs trucs, ça accelère beaucoup les choses.


RE: Petit ensemble de classes - Plume - 04-11-2008

Quand j'dis ça, c'pas comme si j'avais jamais utilisé de génération de formulaire. Et j'suis désolé mais personnellement, les formulaires, j'ai tendance à fortement trouver ça lourd et long à développer entre la génération / la validation / le traitement / ...
Donc si j'dois rajouter la maintenance du code et autre, ça devient une misère. Juste une classe de validation, ça me suffirait =D