Tutoriel PHP : Qu'est ce que le PSR ?

Le PSR, c'est un diminutif qui revient de plus en plus souvent au sein de la communauté PHP lorsque l'on parle d'autoloader (PSR4), de formatage de code (PSR2) ou d'interfaces (PSR7). Mais de qu'est ce qu'un PSR et à quoi corresponds ces chiffres ?

Avant de commencer à parler des PSR, il est important de comprendre le groupe qui est derrière ces standards : le FIG.

Qu'est-ce que le FIG ? Quel objectif ?

L'objectif du FIG est d'améliorer l'interopérabilité entre les Frameworks en réfléchissant à des solutions communes pour uniformiser certaines choses. Le but du groupe n'est pas d'imposer une vision particulière sur la manière de faire les choses, mais plutôt de chercher un moyen de faire fonctionner les frameworks ensemble. C'est d'ailleurs pour cette raison que le groupe, anciennement nommé "PHP Standards Group", a choisi de se renommer en "FIG", pour Framework Interoperability Group, afin de mieux refléter ses objectifs.

Le groupe, représentatif de l'écosystème PHP, émet ses recommandations sous forme de PSR (PHP Standard Recommendation) qui doivent passer par une série d'étapes pour être validées.

• Pre-Draft. Pendant cette phase les membres décident si le concept est intéressant et forment un groupe de travail qui sera responsable de la rédaction du standard.
• Draft. Le groupe de travail créé va travailler sur le standard et le modifier jusqu'à le rendre présentable au Core Committee.
• Review. Pendant cette phase, des implémentations sont essayées. Si, après 4 semaines minimum, 2 implémentations viables peuvent être démontrées, le standard peut passer au vote d'acceptation final.
• Accepté. Si le vote final passe, le standard devient officiellement accepté et le groupe de travail est dissous.
• Déprécié. Un standard peut devenir déprécié si il n'est plus pertinent.
• Abandonné. Un standard peut être abandonné s'il n'y a plus d'activité dessus pendant plus de 6 mois ou suite à un vote du Core Committee.

Slides présentés dans la vidéo

Présentation Slides.com

Recommandations acceptées

Pour le moment 9 PSR ont été acceptées et sont déjà largement adoptées par la communauté.

PSR 1 & PSR 2 : Coding Style

Ces 2 PSR posent des standards concernant le style du code PHP et le formatage à adopter (nombre d'espaces, nommage des classes, placement de la ponctuation...). Il est déjà largement supporté par les IDE et les outils (type PHPCS). La portée de ces PSR sera encore améliorée avec l'arrivée prochainement du PSR12.

PSR 3 : Logger Interface

Ce PSR définit une interface qui permet de représenter un système capable d'écrire des logs. Cette interface LoggerInterface définit 9 méthodes

• 8 méthodes correspondant aux différents niveaux de logs (debug, info, notice, warning, error, critial, alert, emergency).
• 1 méthode plus générique log qui accepte en premier paramètre le niveau d'erreur.

PSR 4 : Autoloading

Venu en remplacement du PSR 0, qui est aujourd'hui déprécié, le PSR4 définit comment le chemin d'un fichier peut être résolu à partir de son namespace. En résumé :

• Un dossier est associé à un namespace spécifique
• Le chemin des classes dans ce namespace doit correspondre au nom du namespace

Par exemple si on spécifie que App\ se trouve dans le dossier src/ alors la classe App\Database\PostRepository sera dans le fichier src/Database/PostRepository.php.

Cette recommandation est importante et permet à des outils comme Composer de fonctionner et de générer un autoloader à partir des dépendances chargées.

PSR 6 : Caching Interface

Comme son nom l'indique, cette PSR permet de définir plusieurs interfaces pour interagir avec le cache. On aura une classe pour représenter le cache de manière globale CacheItemPoolInterface et une autre interface pour définir les objets qui seront mis en caches CacheItemInterface.

PSR 7 : Http Message Interface

Cette recommandation est une des recommandations les plus importantes et définit de nombreuses interfaces liées à la représentation, sous forme d'objets, de messages HTTP

• Une interface générique MessageInterface permet de décrire simplement un message (avec un protocole, des en-têtes et un corps)
• Une interface RequestInterface qui étend la MessageInterface en y ajoutant les concepts de cible, de méthode et d'URL
• Une interface ServerRequestInterface qui étend la RequestInterface avec la gestion des paramètres d'url, des cookies, des fichiers uploadés, des données postées et un système d'attributs permettant de passer des informations.
• Une interface ResponseInterface qui étend la MessageInterface pour représenter une réponse à renvoyer au navigateur (ou reçu suite à un appel à une API) qui ajoute simplement la notion de statut.

En plus de ces interfaces, d'autres interfaces ont été ajoutées pour représenter certains concepts :

• StreamInterface permet de représenter un flux de données et est utilisé pour décrire le corps d'un message.
• UriInterace permet de représenter un lien (schéma, nom d'hôte et chemin).
• UploadedFileInterface représente un fichier uploadé reçu par le serveur et est utilisé par l'interface ServerRequestInterface.

PSR 11 : Container Interface

L'injection de dépendance est devenue un pattern incontournable en PHP et passe nécessairement par un container. Cette recommandation permet d'uniformiser l'accès aux dépendances grâce à la définition d'une interface ContainerInterface qui possède 2 méthodes :

• get(string $id) pour récupérer un élément dans le container
• has(string $id) pour vérifier si un élément existe dans le container

PSR-13 : Link definition interfaces

Sûrement la recommandation la plus spécifique, elle permet, gràce à l'interface LinkInterface, de définir comment représenter sous forme d'objet un lien hypermédia.

PSR 16 : Simple Cache

Cette recommandation fournit les mêmes fonctionnalités que la recommandation PSR 6 mais simplifie l'interface en fusionnant les concepts de Pool et d'Item pour ne proposer qu'une seule interface CacheInterface.

Les recommandations à venir

D'autres recommandations sont en cours d'étude (draft) et permettent d'avoir un aperçu des recommandations à venir.

PSR 5 : PHPDoc Standard

L'objectif est de créer un standard basé sur phpDocumentor afin d'uniformiser les choses et de supporter les nouvelles fonctionnalités de PHP.

PSR 9 & PSR 10 : Security Advisories & Reporting

Plutôt destinées aux éditeurs de Framework / Librairies l'objectif de ces 2 recommandations et de définir le processus pour dévoiler et reporter les problèmes de sécurité.

PSR 12 : Extended Coding Style Guide

Cette recommandation va étendre le PSR 2 en proposant des règles de formatage qui couvrent plus de cas comme par exemple le formatage de namespace multiligne ou le formatage de code PHP mélangé à de l'HTML.

PSR 14 : Event Manager

Cette recommandation permet d'uniformiser le système d'évènement déjà présent sur de multiples frameworks grâce à 2 interfaces.

• EventInterface qui servira à représenter un évènement
• EventManagerInterface qui permettra d'enregistrer les différents "écouteurs" associés à un évènement.

PSR 15 : HTTP Middleware

L'apparition du PSR 7 a permis d'uniformiser la représentation de la requête et de la réponse et a donné lieu à l'adoption du design pattern Middleware. L'objectif de cette recommandation est d'uniformiser la représentation d'un middleware tout en proposant une signature qui limite au maximum les problèmes de conception.

PSR 17 : HTTP Factory

Lorsque l'on choisit dans une méthode de renvoyer une réponse on est obligé de renvoyer une implémentation de l'interface PSR7 ce qui rend notre classe dépendante de cette implémentation. L'objectif de cette recommandation est d'offrir une interface pour des factories liées aux objets HTTP. En injectant la factoy comme dépendance de notre classe, on s'assure de ne plus dépendre d'une implémentation spécifique de Response ou de Request.