Download the PHP package jemdev/form without Composer

On this page you can find all versions of the php package jemdev/form. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package form

À partir de l'objet jemdev\form\form, on appelle simplement la méthode correspondant au type de champs qu'on souhaite créer. Par exemple, pour un champ de type textarea :

On peut cependant ajouter des attributs à ce champ, nous verrons ce point un peu plus loin. Voyons d'abord la liste des champs qu'on peut créer.

champs communs à tous les DOCTYPES

champs propre à HTML5

Notez l'absence du champ input : c'est voulu pour des raisons de simplification. On peut en revanche observer la présence de champs qui correspondent aux types possible d'un champ input : hidden, text, radio, etc... Quel que soit le champ que l'on souhaite créer, la méthode est la même que montrée plus haut avec un textarea.

Les méthodes sur les objets créés à partir de jemdev\form\form

Lorsqu'on crée un champ, la méthode retourne un objet comportant des méthodes qui deviennent utilisables pour compléter certaines propriétés de ce champ.

méthodes communes pour tous les champs

Le résultat correspondra alors à la balise html suivante :

L'exemple utilisé ici permet de souligner un cas particulier : cette balise ne comporte pas d'attribut value, la valeur étant affichée entre les deux balises. Cependant, il est possible d'indiquer le contenu de cette zone de saisie de la même manière que pour n'importe quel autre champ :

Avec le résultat suivant :

Alors qu'avec un champ input de type text, le résultat sera conforme à ce qui est attendu :

Résultat :

Les règles de validation

Il existe déjà des règles génériques disponibles pour valider les données d'un formulaire :

Notez que si un champ n'est pas défini comme requis mais que vous définissez une règles de validation sur le contenu, la validation ne retournera de message d'erreur que si une saisie a été effectuée. Par exemple, un champ où doit être saisie une date ne retournera d'erreur que si une date a été saisie incorrectement, mais la règle sera ignorée si le champ est resté vide et que la règle required n'a pas été définie.

En résumé :

Le principe est simple, la méthode attend les paramètres suivant :

  1. le nom de la règle;
  2. Le message a afficher le la règle n'est pas respectée;
  3. pour certains règles, une valeur de contrôle (minlength, maxlength, minval, maxval, rangeval, inferieur, superieur, regex, validedate, comparer, differentDe);
  4. pour certaines autres règles un seconde valeur de contrôle (rangelength, rangeval) : dans ce cas, le troisième paramètre sera un tableau indexé contenant les deux valeurs à utiliser comme éléments de contrôle.

Le chaînage des méthodes

Dès la création d'un objet pour un champ de formulaire donné, on peut chaîner les méthodes et s'affranchir ainsi de la nécessité de ré-écrire la variable pour chaque appel d'une nouvelle méthode.

Exemple :

Définir des règles de validation personnalisées.

Pour les cas où il ne sera pas possible de définir une expression régulière pour valider un champ donné, il reste possible d'ajouter des méthodes de validation supplémentaires au système de gestion des formulaires. Généralement, ce sera indispensable lorsqu'il s'agira de collecter des informations de contrôle dans une base de données par exemple ou d'une source externe quelconque, ou encore si la donnée considérée doit correspondre à un schéma requérant un calcul de contrôle, par exemple pour vérifier la clé de contrôle d'un numéro de sécurité sociale. Pour ce faire, on définira une classe étendant jemdev\form\process\validation. Pour simplifier, voici un modèle qui pourra vous servir de base :

Le nom de cette classe et la manière dont elle sera chargée dans votre application dépend de vous même et de l'architecture de votre application.

La partie qui nous intéresse essentiellement est la propriété de classe « $aMethodesSupplementaires » où vous indiquerez le nom de la règle qui correspond au nom de la méthode. Ensuite, la méthode de validation : elle reçoit en paramètre au minimum la valeur de la saisie. Le code qu'elle contient dépend de vos propres besoins et devra impérativement retourner un BOOLÉEN. Si vous devez indiquer un autre paramètre, par exemple une valeur de contrôle, vous devrez l'ajouter dans la définition de la méthode ainsi que lors de l'appel de la méthode lorsque vous définirez la règle de validation sur le champ concerné.

Mise en œuvre des méthodes de validation supplémentaires

Pour que vos règles de validation personnalisées soient prises en compte, il convient d'abord de les définir avant la création de l'instance de formulaire. Ensuite, vous devrez préciser lors de la création de cette instance la liste des classes où ces règles supplémentaires devront être trouvées.

Notez que la classe supplémentaire est indiquée en quatrième paramètre lors de la création de l'instance du formulaire. On peut mettre le troisième paramètre à NULL dans la mesure où une valeur sera mise par défaut et automatiquement modifiée si nécessaire lors de l'ajout d'un champ input de type FILE. Vous pouvez maintenant appliquer la règle personnalisée sur le champ approprié comme vu ci-dessus.

NOTE : il n'est pas exclus que le code de la partie validation soit simplifié dans un avenir rapproché de façon à rendre la création de classe de validations supplémentaires moins compliqué même si en pratique ça ne présente actuellement que peu de difficultés.

Intégrer le formulaire dans un gabarit (template)

Il ne reste plus qu'à faire afficher le formulaire, pour ça, on va préparer un gabarit.

Préparer un gabarit (template)

Pour vous simplifier au maximum le travail, préparez un gabarit dont vous pourrez ajuster la mise en forme en HTML. Exemple basique de formulaire tel qu'il sera finalement affiché :

À ce stade, on a besoin que de la partie fieldset, n'utilisez pas la balise <from> qui sera de toutes façons intégrée automatiquement. On va mettre le contenu tel quel dans une variable PHP, ici en utilisant la syntaxe HEREDOC :

Intégrer les champs dynamiques

Maintenant, on va remplacer certaines parties « en dur » par des variables PHP. Le code final ressemblera à ceci :

Observez les lignes où se trouvent les champs : vous pouvez voir qu'on indique les variables entre accolades « { » et « } » et qu'on peut appeler deux propriétés. Ces variables sont en effet des objets et comportent donc des propriété : id et label que vous aurez définis lors de la création des champs. La variable mise seule entre accolade fera appel à la méthode __toString de l'instance qui retournera le code HTML de la balise.

Cette façon de procéder vous laisse toute latitude pour structurer vos formulaires de la manière qui vous convient le mieux, rien n'est imposé à ce niveau et le package jemdev\form ne traite pas du tout l'affichage.

Ajouter le contenu et récupérer le code complet du formulaire.

Une fois votre gabarit défini et vos variables mises en place, et une fois que tous vos champs ont été créés, il ne reste qu'à récupérer le tout prêt à afficher dans votre page.

Notez que le fichier a ici une extension « .phtml » qui est relativement classique, mais rien ne vous empêche d'utiliser une autre extension, du genre « .tpl.php » par exemple. Néanmoins, je recommande « .phtml ».

Important : vous n'avez pas vu l'intégration des champs caché : normal, c'est ajouté automatiquement lors de la dernière opération.

Conclusion

J'ai créé ce package aux environ de 2007 ou 2008 et je m'en sers quotidiennement. Cette version est une refonte intégrant les espaces de nom et composer pour simplifier son utilisation. Si besoin est, faites-moi part de vos observations et/ou questions, je m'efforcerai de trouver le temps nécessaire pour y donner suite.


All versions of form with dependencies

PHP Build Version
Package Version
Requires php Version >=5.4.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package jemdev/form contains the following files

Loading the files please wait ....