L’article de Nicolas Jourdan critique la pratique courante de lier directement les formulaires Symfony aux entités Doctrine, soulignant les problèmes d’architecture qui en découlent. L’auteur explique que cette approche crée un couplage implicite entre la couche de présentation (formulaire) et le modèle métier (entité), transformant cette dernière en simple transporteur de données HTTP. Bien que pratique à court terme, cette méthode introduit des tensions lorsque l’application évolue, notamment en mélangeant les responsabilités (validation, normalisation) et en rendant le code difficile à maintenir.
L’exemple concret d’un formulaire d’inscription à une conférence illustre ces limites. Les règles métier (comme la vérification de la capacité des sessions ou l’expiration des codes promo) finissent par être dispersées entre les contraintes du formulaire et celles de l’entité, complexifiant la logique et réduisant la clarté du code. L’auteur met en garde contre cette approche, qui semble initialement simple mais devient problématique sous la pression des évolutions produit.
Pour remédier à ces problèmes, Jourdan propose une séparation plus nette entre les formulaires et les entités, en utilisant des objets dédiés (DTO) pour capturer les données brutes de l’utilisateur avant de les transformer en entités métier. Cette méthode permet de préserver l’intégrité du domaine tout en gérant plus efficacement les interactions utilisateur, évitant ainsi les compromis architecturaux coûteux à long terme.
Ce guide explique comment renforcer la validation des données dans SQLite, une base de données permissive par défaut. Il propose d'utiliser des clés primaires de type INTEGER PRIMARY KEY NOT NULL, de spécifier explicitement si les colonnes acceptent des valeurs NULL, et d'utiliser le mot-clé STRICT dans les déclarations de tables pour activer des vérifications de type strictes. Le guide aborde également l'utilisation des contraintes CHECK() pour des validations supplémentaires. Idéal pour ceux qui veulent éviter les erreurs de données et les problèmes ultérieurs.
Cet article explique comment gérer proprement les erreurs de validation dans Symfony. L'auteur souligne que, bien que Symfony offre des outils élégants pour la validation des requêtes via les DTOs et les attributs comme #[MapRequestPayload], la gestion des erreurs par défaut reste verbeuse et inconsistante. Il propose une solution propre et moderne en utilisant le bundle Symfony Validation Response, qui transforme automatiquement les erreurs de validation en réponses JSON cohérentes et faciles à consommer pour les clients frontend. L'installation est simple et ne nécessite aucune configuration supplémentaire. L'article inclut un exemple pratique de DTO avec validation et un contrôleur, montrant comment les erreurs sont automatiquement formatées en JSON.
L'auteur explique dans cet article comment utiliser la validation des entrées HTML côté client comme une amélioration progressive pour l'expérience utilisateur, en complément de la validation côté serveur. Il montre comment utiliser les attributs natifs HTML comme pattern, minlength, maxlength, et title pour valider et styliser les entrées, tout en soulignant les limites d'accessibilité de ces méthodes. L'article propose ensuite d'améliorer l'accessibilité en utilisant l'API de validation des contraintes JavaScript pour personnaliser l'affichage des erreurs. Un exemple interactif est disponible sur CodePen.
Ce guide explique comment implémenter la validation dans une architecture Domain-Driven Design (DDD) en suivant une approche par couches. Il souligne l'importance de maintenir l'intégrité des objets de domaine, de valider uniquement ce pour quoi chaque couche est responsable, et d'éviter la duplication de la logique de validation. L'article détaille les meilleures pratiques pour la validation dans la couche de domaine (objets de valeur, entités et services de domaine) et la couche d'application (validation des commandes et orchestration des cas d'utilisation). Il met en avant l'importance de fournir des messages d'erreur clairs et de valider rapidement.
Cet article concerne l’importance des modèles de domaine typés en PHP, renforcés par des outils comme PHPStan et Psalm. L’auteur explique que la sécurité des types permet de préserver l’intégrité architecturale en rendant impossibles les états invalides (ex. : un montant négatif pour une classe Money). Les outils d’analyse statique détectent les violations de contrats, les fuites de nullabilité ou les dépendances architecturales non désirées, là où les tests unitaires peuvent échouer. L’article souligne que modéliser chaque concept métier (comme EmailAddress ou UserId) en tant que type dédié, et utiliser des règles personnalisées dans PHPStan/Psalm, transforme le code en un système fiable et auto-documenté. L’objectif : aligner l’intention des développeurs avec le comportement réel du code, réduisant ainsi la dette technique et les erreurs silencieuses. Une approche progressive est recommandée pour intégrer ces pratiques dans les projets existants.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
L'idée est de pointer visuellement les éléments HTML invalides (accessibilité, validité, etc.)
L'auteur montre l'utilisation des DTOs et des annotations pour la validation de données de requêtes d'API.
Tout est dans le titre
Un guide très complet sur l'accessibilité de la validation des champs de formulaire (avec attributs Aria, bonnes pratiques, etc.)
L'auteur montre l'existence de propriétés JavaScript sur les éléments de formulaire (validity) et comment s'en servir pour customiser l'affichage des erreurs de validation.
L'auteur montre comment utiliser les formulaires Symfony, tout en gardant des entités représentant réellement des concepts du domaine métier. Le point principal est la possibilité de vérifier des contraintes sur la partie "setter" et de donner un nom métier au setter.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre