-
Notifications
You must be signed in to change notification settings - Fork 0
/
MemSymfony.txt
259 lines (168 loc) · 8.68 KB
/
MemSymfony.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
app : fichiers qui concernent l'entièreté du site (configuration)
bin : executables
src : code source
tests : test de l'appli
var : logs, cache, on y touche pas.
vendor : libs externes
web : images, css, js, controleur frontal app.php (le seul accessible aux visiteurs)
En moyenne, on trifouille chez /app et /src
controleur frontal : point d'entrée du programme. Par ici passent toutes les pages. Un
peu l'idée du index.php avec tous les ?var=id qui passent après. Sous symfony c'est app.php
ou app_dev.php
deux environnements :
developpement : app_dev.php [http://localhost:8000/app_dev.php/...] - http://localhost:8000/app_dev.php/Signin/signin
prod : app.php [http://localhost:8000/app.php/...]
si erreurs en mode prod, on peut aller checker chez var/logs/prod.log
Architecture MVC (Modèle / Vue / Contrôleur)
Modèle : gère données et contenu. C'est lui qui réalise les appels à la bdd.
permet au controleur de gérer les données sans savoir comment elles sont stockées
Contrôleur : analyse et traite la requête de l'utilisateur. Chef d'orchestre
vue : afficher les pages. Côté designer. La tronche qu'aura une page
bundle : fonctionnalité.
Ex -> bundle blog qui contient contrôleurs, vues, css, js tout ça d'un blog.
Ex -> bundle user qui gère groupes, mdp, page d'admin des users, formulaire d'inscription, ...
php bin/console generate:bundle
Nom/NombBundle
NomNombBundle
ajouter une structure html
{# src/Nom/NombBundle/Resources/views/Default/index.html.twig #} <html><body> </body></html>
pour le retour de la barre
il faut ajouter une route :
nom_nomb:
resource : "@RCCfAdminBundle/Resources/config/routing.yml" [chemin du routing du bundle]
prefix : "/prefixevoulu"
En résumé, création de bundle :
code source dans src/application/bundleBundle/ avec fichier applicationbundleBundlephp
à la racine
enregistrer le bundle dans le noyau app/AppKernel.php avec new application/bundle...
enregistrer les routes en modifiant app/config/routing.yml
suppression de bundle :
1 - l'enlever de AppKernel.php
2 - l'enlever du app/routing.yml et du app/config.yml
3 - virer le dossier du bundle
4 - virer les assets du bundle (dans web/...)
5 - éliminer les dépendances inter bundle.
Création d'une page :
1 - déf URL en changeant Resources/config/routing.yml /!\ 4 ESPACES - PAS DE TAB /!\
nom_route:
path: /url
defaults: {_controller: RCCFAdminBundle:Advert:index}
defaults : paramètres de la route
_controller : action que l'on veut éxecuter et controleur (advert) que l'on va appeler.
RCCFAdminBundle -> nom du bundle
Advert : nom du contrôleur à ouvrir
index : nom de la méthode à éxecuter dans le contrôleur.
on ajoute pas les nouvelles routes dans app/config/routing.yml puisque elles sont internes
au bundle -> encapsulation.
Il faut créer les contrôleurs , AdvertController.php dans l'exemple.
pour chaque action définie dans defaults (cf routes) il faut une méthode actionAction(),
par ex indexAction().
Dans le contrôleur on met le minium de html tout ça, on se repose sur les templates Twig.
vider le cache du mode prod
1 - php bin/console cache:clear --env=prod
2 - OU manuellement vider var/cache/{dev, prod}
Explication sur le routing en Symfony
on touche au fichier nomBundle/Resources/config/routing.yml
path : entrée - url à capturer
defaults : paramètres de la route, quel contrôleur appeler.
possibilité de mettre des jockers /url/{id} catchera les url du type /url/5
en plaçant 5 pour la variable id.
# src/OC/PlatformBundle/Resources/config/routing.yml
oc_platform_home:
path: /platform
defaults: { _controller: OCPlatformBundle:Advert:index }
oc_platform_view:
path: /platform/advert/{id}
defaults: { _controller: OCPlatformBundle:Advert:view }
oc_platform_add:
path: /platform/add
defaults: { _controller: OCPlatformBundle:Advert:add }
oc_platform_... -> nom de la route
path : /... -> URL sur laquelle la route s'applique
defaults : paramètre de sortie de la route.
dans les lignes _controller :
OCPlatformBundle -> nom du Bundle
Advert -> nom du controleur (cf AdvertController.php)
view -> nom de l'action à exécuter (cf viewAction())
si {id} est mentionné dans le path, il est alors obligatoire par défaut
pour que l'URL matche
# src/OC/PlatformBundle/Resources/config/routing.yml
oc_platform_view_slug:
path: /platform/{year}/{slug}.{format}
defaults:
_controller: OCPlatformBundle:Advert:viewSlug
format: html # donne une valeur par défaut à format
requirements:
year: \d{4} # 4 chiffres
format: html|xml # l'un ou exclusif l'autre
paramètres système : (appellent directement le Kernel de Symfony)
_format -> ajoute un paramètre Content-type à la réponse
_locale -> langue, pas oublier les requirements (si le gars demande russe alors
qu'il y a que anglais et français à proposer ...)
_controller -> le contrôleur à appeler
possibilité d'ajouter des préfixes, avec le param prefix dans app/config/routung.yml
pour récupérer une requête dans un contrôleur (pour gérer les arguments du type ?tag=24 dans
les url)
use Symfony\Component\HttpFoundation\Request;
use Symfony\Bundle\FrameworkBundle\Controller\Controller;
class LeControleur extends Controller {
public function viewAction($p1, Request $p2){ //p2 est la requete site/page?tag=5
$tag = $request->query->get('tag');
// ...
}
}
tableau des variables :
type de param méthode symfony méthode php exemple
Variables d'URL $request->query $_GET $request->query->get('tag')
Variables de formulaire $request->request $_POST $request->request->get('tag')
Variables de cookie $request->cookies $_COOKIE $request->cookies->get('tag')
Variables de serveur $request->server $_SERVER $request->server->get('REQUEST_URI')
Variables d'entête $request->headers $_SERVER['HTTP_*'] $request->headers->get('USER_AGENT')
Paramètres de route $request->attributes n/a $request->attributes->get('id')
Rmq : si le paramètre n'existe pas, on retourne une chaine vide et non une erreur (donc pas
besoin de tester l'existence).
si un formulaire est envoyé -> méthode POST |
| } isMethod()
si sur un clic -> méthode GET |
requête AJAX ? isXmlHttpRequest() -> pratique pour renvoyer du JSON
http://api.symfony.com/3.0/Symfony/Component/HttpFoundation/Request.html
possibilité de construire une réponse complète avec les méthodes de l'objet Response
setContent(), setStatusCode().
la méthode render() permet d'éviter de se payer l'enchaînement des méthodes.
Une redirection est une requête HTTP avec unp paramètre Location. On peut utiliser l'objet
Redirect Response
class AdvertController extends Controller {
public function viewAction($id) {
$url = $this->get('router')->generate('oc_platform_home'); // definit l'url de redirection
return new RedirectResponse($url); // redirection
// ou return $this->redirect($url);
// ou le tout en une seule ligne
// return $this->redirectToRoute('oc_platform_home');
}
}
petit point config : en mettant intercept_redirects = true dans app/config/config_dev.yml
on peut avoir un visuel symfony sur les pages excecutées tout ça, au lieu d'être redirigé
salement.
Le contenu d'une réponse dépend du paramètre Content-type dans le header de celle-ci.
on peut par exemple renvoyer du JSON avec un objet JsonResponse par exemple.
On peut gérer les sessions avec [objet request] $request->getSession
message flash -> variable de session qui ne vit que sur une seule page.
$this->addFlash(
'notice',
'success!'
);
Composer : est au PHP ce qu'APT est à nunux.
Notions de service -------------------------------------------------------------
Un objet = objet PHP (donc classe !) remplissant une fonction, associé à une config.
est accessible depuis n'importe où dans le code. La configuration c'est l'enregistrer
dans le conteneur de service, en lui donnant un nom, sa classe, tout ça.
Entités ------------------------------------------------------------------------
ORM -> object relation mapper. ORM manipule des entités (objets). Pour indiquer à la BD
quels types de données doivent être donnés tout ça, on utilise les commentaires /* @ */,
ce sont des annotations.
to be continued
Sécurité et Users ---------------------------------------------------------------
ressources : http://symfony.com/doc/current/security.html
1 - Authentification => security.yml
2 - Authorization => interdire l'accès
3 - utiliser l'objet user.