L'article explique pourquoi il est préférable d'utiliser des objets de transfert de données (DTO) avec les formulaires Symfony plutôt que des entités. Bien que l'utilisation directe des entités dans les formulaires soit simple et efficace pour des opérations CRUD basiques, elle peut devenir complexe et problématique pour des cas d'utilisation plus avancés.
L'auteur illustre cela avec un exemple où un formulaire d'édition d'utilisateur doit gérer des champs d'adresse conditionnels. Utiliser directement les entités nécessite des ajustements complexes, comme des transformateurs de données, et peut mener à des états incohérents des entités.
En revanche, l'utilisation de DTOs permet de séparer clairement les données du formulaire de la logique métier, rendant le code plus maintenable et compréhensible. Les DTOs représentent exactement les données du formulaire, évitant ainsi de modifier les entités pour s'adapter aux besoins du formulaire.
Bien que cela nécessite un peu plus de code pour mapper les données entre les DTOs et les entités, cette approche est plus flexible et évite les inconvénients liés à l'utilisation directe des entités dans les formulaires
Apprendre le développement web : accessibilité, HTML, images, responsive web design, PWA, formulaires, et CSS avec les équipes de Google
Tout est dans le titre
Des recommandations et bonnes pratiques
Pour résumer :
- aligner le bouton principal à gauche (bord gauche des inputs)
- mettre le bouton de retour au dessus du formulaire
- mettre les boutons d'actions relatifs au dessus du formulaire (ex: mot de passe oublié)
- placer les boutons supplémentaires par rapport à ce qu'ils font
- pour un formulaire avec un champ unique, mettre le bouton près de l'input
- pour un formulaire avec un champ de sélection multiple, placer les boutons avant le formulaire
Tout est dans le titre
De bons conseils pour des formulaires utilisables
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
L'auteur explique comment son équipe a redéfini l'outil de recherche avancé de Spokeo :
- l'outil est plus facile à trouver (non masqué par défaut)
- il est plus explicite (avec un titre disant ce qu'il fait, des champs de saisie bien expliqués, et la soumission du formulaire n'est plus automatique, il faut une confirmation de l'utilisateur)
- les champs sont regroupés par sections logiques
- certains champs ambigus ont été remplacés, comme la combinaison ville / état remplacée par le choix de l'état, puis de la ville
- chaque champ est placé dans une ligne - comme les champs sont regroupés dans des sections fermées par défaut, le formulaire est plus clair
- pour le mobile, l'accès au formulaire se fait via un bouton flottant placé en pied d'écran
Tout est dans le titre (via http://makina-corpus.com/blog/metier/2016/butinage-94 )
L'auteur part du constat d'un problème courant à beaucoup de bibliothèques de validation de formulaire : du code fortement couplé. Dans un premier article, il a présenté les bénéfices d'une séparation orthogonale des préoccupations, en développant un système de validation non restreint aux formulaires, et qui peut même fonctionner en dehors du DOM. Dans cet article, il parle des validateurs composés, comment récupérer les données d'un formulaire, et comment afficher les erreurs.
Des bouts de code CSS3 pour customiser l'apparence des formulaires (via http://www.inpixelitrust.fr/blog/la-semaine-en-pixels-17-avril-2015-2/ )
Parfaitement expliqué, tout est dans le titre
Le titre est un peu trompeur, l'auteur s'attache à démontrer les bienfaits d'un couplage faible. Il choisit comme cas particulier de s'attaquer à la validation des formulaires.
Des démos CSS très intéressantes : formulaires, menus, "blocs ouvrables", etc.
Des démos CSS3 / HTML5 pour les formulaires
Des styles pour éléments de formulaires difficiles à styler (checkbox, radio, select)