EtuUTT DocumentationVersion 10.1

tgalopin

17 April 2015

Table des matières

1 Accéder aux données étudiantes et associatives avec l’API 31.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Obtenir un accès à l’API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Utiliser l’API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Liens complémentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Contribuer au site étudiant : créer des modules et modifier le code principal 132.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Introduction et conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Développer un module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4 Tester et déployer EtuUTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Utiliser les librairies de l’UNG pour accéder aux données de l’UTT 173.1 PHPUTT - Les données publiques de l’UTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

i

ii

EtuUTT Documentation, Version 10.1

Cette documentation a pour vocation de permettre à chaque développeur de l’UTT de travailler avec EtuUTT ou avecles ressources associées.

Elle aborde trois thèmes :

Table des matières 1

EtuUTT Documentation, Version 10.1

2 Table des matières

CHAPITRE 1

Accéder aux données étudiantes et associatives avec l’API

1.1 Introduction

Cette partie introduit les concepts généraux de l’API d’EtuUTT et explique les choix techniques.

Nous aborderons la partie pratique dans a prochaine partie : pour le moment, parlons des technologies utilisées.

1.1.1 Fonctionnement général et vue d’ensemble

L’API d’EtuUTT utilise REST, JSON et OAuth pour donner aux développeurs de l’UTT un accès aisé aux donnéesétudiantes et associatives.

Cette API est codée au sein même du site étudiant (elle utilise donc elle aussi Symfony2). Vous pouvez retrouver lecode du site et de l’API sur Github :

http://github.com/ungdev/site-etu

Outils requis et recommandations

Note : Les outils listés ci-dessous vous sont requis dans le cas où vous créez une application réelle. Pour testerl’API, vous pouvez utiliser des interfaces comme Postman (https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm) qui vous permettront d’effectuer des requêtes visuellement.

Méthode d’accès

L’API d’EtuUTT se base activement sur HTTP. La méthode recommandée pour y accéder est donc d’utiliser un clientHTTP dans votre language de programmation. Par exemple, pour PHP, Guzzle est un client HTTP complet et très bienfait.

Stockage

L’API d’EtuUTT utilise des tokens d’authentifications pour limiter l’accès des applications aux données privées ac-ceptées par l’utilisateur. Vous devez donc avoir à votre disposition un moyen de stocker ces tokens d’accès pendantplusieurs jours (typiquement, une base de données).

Cache

L’API d’EtuUTT peut tout à fait servir de base de donnée pour vos applications. Cependant, étant donné que chaquerequête passe par le réseau, votre application pourrait être ralentie pendant cet accès à l’API. N’hésitez pas à mettre enplace du cache de votre coté pour éviter les requêtes inutiles.

3

EtuUTT Documentation, Version 10.1

Note : Même si il n’y a pas de limite du nombre de requêtes par jour, il est de bonne augure d’éviter le plus possibleles requêtes inutiles, ceci pour garder une infrastructure stable et ne pas surcharger la plateforme.

En bref, pour commencer à utiliser l’API, vous devriez avoir à votre disposition :— une base de donnée ou toute autre méthode de stockage (nécessaire à l’utilisation des tokens) ;— un système de cache (nécessaire pour le bien de tous) ;— un client REST dans votre language de programmation favrois (optionnel mais utile) ;

1.1.2 OAuth : qu’est ce que c’est

La partie de loin la plus complexe à utiliser de l’API est OAuth. Pour ceux ne connaissant pas, OAuth est un protocoled’authentification qui a pour particularité de ne pas utiliser le mot de passe utilisateur.

Pourquoi utiliser OAuth ?

Pourquoi est-que nous avons besoin d’OAuth ? La question est importante car sa réponse explique le fonctionnementdu protocole en lui-même.

L’objectif de l’API EtuUTT est d’autoriser des applications externes (non développées par l’UNG) à accéder à desdonnées qui pourraient s’avérer sensibles. Il faut donc que l’utilisateur de l’application doive donner son accord pourque l’application puisse accéder à ses données sensibles. Et pour cela il faut que cet utilisateur sache exactement àquelles données l’application pourra accéder.

C’est à cela que sert OAuth. Etant donné qu’une application externe ne devrait jamais avoir à gérer le mot de passe deses utilisateurs, OAuth met en plce un système basé sur un échange de tokens pour accéder à des données privées avecle consentement de l’utilisateur.

Comment fonctionne OAuth ?

Le fonctionnement d’OAuth est le suivant :

Il y a trois parties en jeu :— l’Utilisateur, la personne qui utilise votre application ou votre site internet ;— le Client, votre application ou votre site internet ;

4 Chapitre 1. Accéder aux données étudiantes et associatives avec l’API

EtuUTT Documentation, Version 10.1

— EtuUTT qui s’occupe d’autoriser les Clients à accéder aux données des Utilisateurs ;Les étapes de fonctionnement d’un processus classique OAUTH sont :

1. Vous déclarer votre application auprès d’EtuUTT en créant un client et en listant les droits dont vous avezbesoin dans votre application (à quoi vous voulez accéder) ;

2. EtuUTT vous attribue alors un client id et un client secret qui vous serviront pour utiliser l’API ;

3. Au moment où l’utilisateur veut se connecter en utilisant votre application, vous le redirigez vers une adressespécifique d’EtuUTT (que nous verrons plus en détail par la suite), et EtuUTT demandera à l’utilisateurconnecté actuellement si il souhaite donner ses informations à votre application ;

4. Si l’utilisateur accepte, il est redirigé vers votre application avec un code d’autorisation ;

5. Ce code d’autorisation vous permet alors de demander un token d’accès qui sera votre clé pour utiliserconcrêtement l’API ;

6. Un token d’accès et un refresh token vous sont attribué : le premier vous sert à accéder à l’API et n’est validequ’une heure, le deuxième vous permet de regénérer à volonté des tokens d’accès et est valide un mois ;

7. Vous dialoguez avec l’API grâce au token d’accès en lui demandant des données ...

8. ... qu’elle vous fournit si vous y avez accès ...

9. ... et que vous pouvez donc fournir à l’utilisateur ;

Cela peut paraitre complexe et difficile d’accès pour le moment, mais vous verrez que dès que nous le mettrons enplace, vous comprendrez rapidement le fonctionnement.

Petite remarque : comme vous pouvez le voir, aucun échange de mot de passe passant par le Client n’a eu lieu. Toutse fait à partir d’EtuUTT qui fournit des tokens à ce client.

1.1.3 Conventions REST, JSON

Le principe de base de toute API est de faciliter le dialogue et la transmission d’information entre deux applications.Une API est tout simplement un lot d’URL utilisables facilement depuis un programme, quel qu’il soit.

Pour faciliter ce dialogue entre machines, il est essentiel que chacun suive les mêmes conventions.

Avant de nous lancer dans la mise en pratique, il faut fonc que l’on aborde les deux standards utilisés par EtuUTT pourla transmission de données : REST et JSON.

REST

REST est une méthode d’organisation d’URL pour API. REST fournit en quelque sorte le squelette de l’API.

La méthode REST est très liée au protocole HTTP et essaie de l’utiliser au maximum de ses possibilités : le but estde décrire des ressources par des URL et d’utiliser les méthodes HTTP comme des actions sur ces ressources. Parexemple :

GET /users/1 Retourne les informations sur l’utilisateur d’identifiant 1POST /users Créer un utilisateurPUT /users/1 Modifie l’utilisateur d’identifiant 1

DELETE /users/1 Supprime l’utilisateur d’identifiant 1

De cette manière, les URL sont cohérentes et simples d’utilisation. C’est cette convention que l’API d’EtuUTT suitpour ses URL.

Note : Pour en savoir plus sur REST :

http://fr.wikipedia.org/wiki/Representational_State_Transfer http://www.figer.com/Publications/REST.htm#.U9kPu_l_tOY

JSON

1.1. Introduction 5

EtuUTT Documentation, Version 10.1

JSON est un format de données. Là où REST est le squelette de l’API, JSON est sa langue. C’est un format standard,inter-languages, qui permet de partager des données facilement entre machines.

Il est très comparable à XML, si ce n’est qu’il est beaucoup moins verbeux et plus facile à lire à l’oeil humain.

Il existe des décodeurs JSON dans presque tous les languages de programmations, à vous de trouver le vôtre (ledécodeur JSON est natif dnas beaucoup de languages) !

Note : Pour en savoir plus sur JSON :

http://fr.wikipedia.org/wiki/JavaScript_Object_Notation http://json.org/

Note : Toutes les réponses de l’API d’EtuUTT auront ce format :

{"http": {

"status": <status_code>,"message": "<status_message>"

},"response": <reponse_data>

}

Il vous est donc très simple de vérifier qu’une requête n’a pas échoué.

1.2 Obtenir un accès à l’API

Maintenant que nous avons introduit les concepts, nous pouvons passer à la mise en pratique.

1.2.1 Créer son application

La première étape pour accéder à l’API est de créer une application sur EtuUTT. Pour cela, tout se passe sur le site,plus particulièrement sur le panel pour développeurs :

6 Chapitre 1. Accéder aux données étudiantes et associatives avec l’API

EtuUTT Documentation, Version 10.1

1.2. Obtenir un accès à l’API 7

EtuUTT Documentation, Version 10.1

C’est d’ailleurs probablement par le biais de ce panel que vous avez découvert cette documentation.

Cliquez sur Créer une application. Quelques informations à propos de votre application vous sont alors demandées :— le nom : il sera affiché sur la page d’autorisation utilisateur ;— l’URL de redirection : l’URL vers laquelle l’utilisateur sera redirigé si il accepte l’accès ;— une image, qui sera redimensionnée en 150x150 pixels et qui représentera votre application ;— des droits : de quoi aura besoin votre application ? A quelles données voulez-vous qu’elle puisse accéder.

Mettre tout n’est pas utile et risque même de faire fuir les utilisateurs : demandez seulement ce dont vous avezbesoin ;

Note : N’hésitez pas à acréer des applications de test, vous pourrez les supprimer par la suite si vous ne les utilisezplus.

Note : Pour les applications mobiles, l’URL de redirection utilise une petite astuce. Nous l’aborderons dans la suitede la documentation.

Une fois créée, il vous est attribué deux données essentielles pour votre application :— un Client ID, correspondant à l’identifiant de votre application ;— un Client Secret, correspondant au mot de passe de votre application ;

Ces deux données sont privées, tout particulièrement le Client Secret. Ne les partagez avec personne, sous peine devoir votre application utilisée à mauvais escient.

1.2.2 Les types d’authentification et les scopes

Pour accéder à l’API, il faut vous identifier voire même identifier l’utilisateur connecté pour accéder à ses données. Ilvous faut donc utiliser OAuth, comme nous l’avons vu précédemment. Or, il existe plusieurs manière de s’authentifieravec OAuth : ces méthodes s’appellent les grant_types.

Le but de chacun de ces grant_type est d’obtenir un access_token, un token d’accès à l’API. Selon ce dontvous avez besoin dans votre application, vous devrez générer cet access_token différemment.

Les scopes

Avant d’essayer d’obtenir un accès à l’API avec un access_token, il nous faut parler un peu des scopes.

Qu’est-ce qu’un scope

Un scope est une permission associée à un client ou à un access_token.

En bref, vous ne pouvez accéder à certaines parties de l’API que si vous avez ces scopes enregistrés dans votre token.Or, l’utilisateur doit valider ces scopes pour que vous y ayez accès : ce de la que vient la force d’OAuth.

Il existe par exemple les scopes suivants :

public Accès aux données publiquesprivate_user_account Accès aux données privées de l’utilisateur actuelprivate_user_schedule Accès aux données d’emploi du temps de l’utilisateur actuel

Lorsque vous avez créé votre application, pour chaque droit que vous avez demandé, un scope a été associé à votreclient. Et lorsque vous demanderez un access_token à l’utilisateur, il lui sera demandé si il accepte de vous donner cesinformations.

8 Chapitre 1. Accéder aux données étudiantes et associatives avec l’API

EtuUTT Documentation, Version 10.1

Accéder aux données publiques seules : client_credentials

Si vous n’avez besoin d’accéder qu’aux données publiques mises à disposition par l’API, vous n’avez pas besoin dedemander d’accès à l’utilisateur, car les données sensibles ne vous intéresse pas. Vous pouvez donc utiliser le typed’authentification appelé client_credentials.

Ce type d’authentification utilise les identifiants fournit par EtuUTT à votre client (le client ID et le client secret) pourcréer un accès ne possédant que le scope public.

Ce type d’authentification est idéal pour commencer car il est très simple. Par exemple, pour obtenir un token d’accèsavec client_credentials, en PHP avec Guzzle :

$client = new Client([’base_url’ => ’https://etu.utt.fr/’,’defaults’ => [

’auth’ => [’<client_id>’, ’<client_secret>’]]

]);

$response = $client->post(’/api/oauth/token’, [ ’body’ => [’grant_type’ => ’client_credentials’,

]]);

var_dump($response->json());

Vous obtenez alors quelque chose ressemblant à :

{"http": {

"status": 200,"message": "OK"

},"response": {

"access_token": "4b8f0f6dccf3ccd998ae090f7f9afc37083667b7","expires_in": 3600,"token_type": "Bearer","scope": "private_user_account private_user_schedule private_user_organizations public"

}}

Comme vous le comprenez probablement, vous avez dans ce résultat :— un token d’accès : 4b8f0f6dccf3ccd998ae090f7f9afc37083667b7. C’est ce token qu’il faudra

garder pour effectuer de multiples requêtes avec son autorisation ;— la date d’expiration du token d’accès, ici dans 1 heure (3600 secondes) ;— un type de token (Bearer) qui ne vous intéresse pas (cela correspond à la confiance accordée au cient par

EtuUTT) ;— Une liste de scopes qui ont été donnés au token : ici, vous pouvez donc accéder aux données publiques (vous

avez le scope public) ;

Note : Vous vous demandez probablement pourquoi vous avec les scopes private_user_account,private_user_schedule, private_user_organizations alors que je vous ait dit que vous ne pouriezaccéder qu’aux donnée publiques de l’API.

Et bien l’idée est simple : si vous utilisez le type client_credentials, vous povuez automatiquement accéderaux données de l’utilisateur gérant l’application comme si vous étiez connecté. Cela signifie donc que vous pouvezaccéder à vos propres données si vous avez créé ce client.

1.2. Obtenir un accès à l’API 9

EtuUTT Documentation, Version 10.1

Accéder aux données privées d’un utilisateur : authorization_code

Vous êtes désormais capable de récupérer un token d’accès pour votre application. Cependant, même si nous n’avonspas encore récupéré de données avec, ce token sera limités aux données publiques ou à vos propres données (quiintéressent peu vos utilisateurs).

Venons en maintenant à créer un token pour accéder aux données de l’utilisateur connecté à EtuUTT.

Pour cela il nous faut passer par le type authorization_code. Cependant, ce code nécessite une autorisation parl’utilisateur. Il y a donc deux étapes pour récupérer notre token d’accès :

1. Rediriger l’utilisateur vers :

http://etu.utt.fr/api/oauth/authorize?client_id=<client_id>&scope=public%20private_user_account&response_type=code&state=xyz

client_id correspondant à votre client ID, et scopes est la liste des scopes dont vous avez besoin pour letoken séparés par des espaces ;

2. Récupérer le code d’autorisation pour créer un token d’accès ;

Quand vous allez sur :

http://etu.utt.fr/api/oauth/authorize?client_id=<client_id>&scope=public%20private_user_account&response_type=code&state=xyz

vous pouvez vous rendre compte d’à quoi ressemblera votre page d’autorisation.

Si vous cliquez sur “Accepter”, vous serez alors redirigés sur votre application avec un paramètre code :

https://myapp.com/redirect_url/?code=65707fb5aa64db8c5c73983e22081b2dbab54c51&state=xyz

Par exemple, ici nous avons récupéré un code d’authorisation : 65707fb5aa64db8c5c73983e22081b2dbab54c51

Ce code est valide pendant 30 secondes et est transformable en token d’accès une seule fois, donc ne traînez pas !

Prenons un exemple : j’ai créé mon application avec comme adresse de retour https://myapp.com/auth.php.Dans mon fichier auth.php, j’ai :

$client = new Client([’base_url’ => ’https://etu.utt.fr/’,’defaults’ => [

’auth’ => [’<client_id>’, ’<client_secret>’]]

]);

$response = $client->post(’/api/oauth/token’, [ ’body’ => [’grant_type’ => ’authorization_code’,’authorization_code’ => $_GET[’code’]

]]);

var_dump($response->json());

Nous avons alors une réponse de la forme :

{"http": {

"status": 200,"message": "OK"

},"response": {

"access_token": "a314da50ed469583a8377aff96848aa3300777e8","expires_in": 3600,"token_type": "Bearer",

10 Chapitre 1. Accéder aux données étudiantes et associatives avec l’API

EtuUTT Documentation, Version 10.1

"scope": "public private_user_account","refresh_token": "f7fc59610c2a7fa8365c87b4f93b589e50826618"

}}

Comme précédemmant, c’est la clé access_token qui nous intéresse le plus pour accéder à l’API.

Cependant, nous en avons une supplémentaire : le refresh_token. Cela correspond à un autre grant_type, abordé dansle document suivant.

Rafraichir un token d’accès : refresh_token

Alors qu’avec client_credentials vous pouviez demander autant de token que vous vouliez, avec leauthorization_code vous avez besion de l’approbation de l’utilisateur à chaque fois que vous voulez un to-ken. Cependant, ces tokens ne durent qu’une heure : vous ne pouvez pas demander à l’utiisateur d’accepter votreapplication toutes les heures !

Le refresh_token est une solution à ce problème : ce token est valide un mois entier et permet de regérérer destokens d’accès. Stockez donc le en base de donnée, il est important !

Par exemple, avec le refresh_token ci-dessus :

<?php

$client = new Client([’base_url’ => ’https://etu.utt.fr/’,’defaults’ => [

’auth’ => [’<client_id>’, ’<client_secret>’]]

]);

$response = $client->post(’/api/oauth/token’, [ ’body’ => [’grant_type’ => ’refresh_token’,’refresh_token’ => ’f7fc59610c2a7fa8365c87b4f93b589e50826618’

]]);

var_dump($response->json());

Nous avons une réponse de la forme :

{"http": {

"status": 200,"message": "OK"

},"response": {

"access_token": "ed7653ce2cfce53ee96efb3ed485ecbcecc83545","expires_in": 3600,"token_type": "Bearer","scope": "public","refresh_token": "579a9f9f5545f90002916aaebf5d9346070eb7c0"

}}

Note : Quand vous demandez un token d’accès avec un refresh_token, ce refresh_token est supprimé (il n’est plusutilisable) et un aute est regénéré, présent dans la réponse, comme ci-dessus. Cest ce nouveau refresh_token qu’ilfaudra utiliser.

1.2. Obtenir un accès à l’API 11

EtuUTT Documentation, Version 10.1

1.2.3 Utiliser le token d’accès

Quelque soit la méthode que vous avez utilisé pour récupérer un token d’accès (cf doc précédent), vous êtes désormaisen sa possession. Pour l’utiliser, rien de plus simple : il vous suffit de passer en argument de votre requête le paramètreaccess_token contenant votre token d’accès

.. code:: text

https://etu.utt.fr/api/orgas?access_token=a314da50ed469583a8377aff96848aa3300777e8

1.3 Utiliser l’API

Vous pouvez trouver toutes les points d’entrée de l’API sur la Référence des points d’entrées. Cette partie expliquecomment utiliser l’API de manière générale snas forcément aborder tous ces points d’entrée dans le détail. A vous detester et d’experimenter !

1.3.1 Les données publiques

Note : Toutes les URL de données publiques sont préfixées de /api/public, par exemple :

/api/public/users/api/public/orgas

Il existe de nombreuses données publiques mises à disposition des étudiants par l’UTT, principalement concernant sesétudiants et son personnel (via l’annuaire LDAP). Cependant, cet accès est limité à l’intérieur de l’UTT et ne permetdonc pas de développer aisément des applications ou des sites internet en les utilisant.

L’API d’EtuUTT résoud ce problème en proposant ces données et d’autres récoltées à partir des étudiants eux-mêmedirectement à travers OAuth.

Ces données publiques sont en lecture seule (vous ne pouvez y accéder que par la méthode GET) et ne requierentaucun scope spécial.

1.4 Liens complémentaires

— Référence des points d’entrée

12 Chapitre 1. Accéder aux données étudiantes et associatives avec l’API

CHAPITRE 2

Contribuer au site étudiant : créer des modules et modifier le codeprincipal

2.1 Installation

La première chose à faire avant de pouvoir développer sur le site étudiant est d’installer un environnement propre etpratique.

Chaque plateforme a sa manière de faire, mais nous allons aborder les méthodes les plus classiques pour installer lesite étudiant sur votre machine afin que vous soyez apte à développer.

2.1.1 Installation sous Windows

2.1.2 Installation sous Linux

2.1.3 Installation sous Mac OS X

2.2 Introduction et conventions

2.2.1 Fonctionnement général et introduction

2.2.2 Conventions de développement

Afin de pérenniser EtuUTT et de pouvoir garder ce projet sain et propre, il faut que chaque développeur ayant l’occa-sion de modifier le code le fasse comme tous les précédents.

Pour cela, il existe des normes et des conventions d’organisation, de codage et de mise en place pour essayer d’unifor-miser les manières de développer.

Le code et PHP-FIG

PHP-FIG est l’abbréviation de PHP Framework Interop Group (http://www.php-fig.org), un groupe de développeursqui a voulu amener dans le monde de PHP des conventions de codages que chacun pourra utiliser.

Ces conventions sont appelées les PSR. Il en existe quatres, de plus en plus contraignantes :— PSR-0 : Autoloading Standard— PSR-1 : Basic coding standard— PSR-2 : Coding Style Guide

13

EtuUTT Documentation, Version 10.1

— PSR-3 : Logger interfaceChacune des convention hérite des contraintes de la précédente et en ajoute.

Symfony suit la convetion PSR-2 au moment où j’écris ces lignes (avril 2013). PSR-3 n’étant pas spécialement utile àEtuUTT, nous nous contenterons de PSR-2.

En d’autres mots, il y a trois conventions que vous devez suivre :— https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md— https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md— https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md

Ces conventions sont nécessaires à la bonne conduite du projet, essayez de les suivre le plus possible.

Les modules et les bundles

Création

Etant donné que les modules seront normalement créés grâce à la ligne de commande, il n’y a a priori pas de conventionprécise quant à leur développement. Cependant, si vous souhaitez créer un module à la main, le meilleur moyen est decopier un module déjà existant et de modifier ses namespaces et ses classes pour ne rien oublier.

Organisation

La convention de Symfony nous propose de ne rien mettre mise à part la classe de base dans le dossier racine dubundle. Les dossiers et les namespaces nous aidant beaucoup pour cela, il faut suivre cette convention.

— Les contrôleurs sont stockées dans Controller— Les extensions du conteneur de services sont stockées dans DependencyInjection— Les entités sont stockées dans Entity— Les vues sont stockées dans Resources/views— La documentation est stockée dans Resources/doc— La configuration est stockée dans Resources/config— Les traductions sont stockées dans Resources/translations— Les extensions Twig sont stockées dans Twig et sont suffixées de Extension— Les traductions sont stockées dans Resources/translations— Les commandes sont stockées dans Command— Les types de champs de formulaires sont stockés dans Form— Les classes outils (classes généralistes utiles partout) sont stockés dans Util— Les helpers de notifications (classes d’affichages de notifications, cf 3.) sont stockées dans

Notification/Helper— Les listeners sont stockées dans Listener— Les tests sont stockés dans Tests et suffixés de Test.php

Ensuite, si vous avez des éléments ne correspondant pas à cette liste, n’hésitez pas à créer un dossier plus spécifique(par exemple, il existe Imap, Ldap, ... dans le EtuUserBundle).

Les entités

Les entités correspondent à des tables dans la base de donnée. Or, pour s’organiser le mieux possible, il est de bonneaugure de donner des noms évocateurs à ces tables.

Pour cela, une convention existe : prenez le nom de l’entité au pluriel, mettez la en minuscule et avec des underscorespour séparer les mots et préfixez-lui “etu_”. Par exemple : Issue devient etu_issues.

Pour les entités dépendantes en relation OneToMany à d’autres entités, il faut là aussi préfixer le nom de l’entité pourmontrer le lien entre les tables. Ici, par exemple, un commentaire sur un bug correspond à un lien OneToMany entreIssue et Comment. L’entité Comment aura donc pour nom de table etu_issues_comments.

Note : Pour modifier les nom des tables créées, utilisez les annotations :

14 Chapitre 2. Contribuer au site étudiant : créer des modules et modifier le code principal

EtuUTT Documentation, Version 10.1

namespace Acme\DemoBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

/*** @ORM\Table(name="table_name")

* @ORM\Entity

*/class Entity{

// ...}

2.3 Développer un module

2.3.1 Créer et installer un module

2.3.2 Développer dans un module

2.3.3 Les assets, Assetic, Bower

2.3.4 Les utilisateurs et les organisations

2.3.5 Les formulaires

2.4 Tester et déployer EtuUTT

2.4.1 Teser le fonctionnement du site

2.4.2 Déployer en préproduction / production

2.3. Développer un module 15

EtuUTT Documentation, Version 10.1

16 Chapitre 2. Contribuer au site étudiant : créer des modules et modifier le code principal

CHAPITRE 3

Utiliser les librairies de l’UNG pour accéder aux données de l’UTT

3.1 PHPUTT - Les données publiques de l’UTT

17