Index :


Présentation de symfony

L’utilisation d’un framework comme symfony est un des moyens les plus faciles d’augmenter votre vitesse et votre efficacité en tant que développeur web. Le framework est livré avec de nombreuses fonctionnalités utiles qui vous aident à se concentrer sur la logique métier de votre application plutôt que sur la mise en Å“uvre d’un objet d’une autre page ou sur une autre couche d’abstraction de base de données. Cependant, cela a aussi un coût, l’étude de toutes les fonctions disponibles et toutes les possibilités de configuration incorporées n’arrivent pas subitement.
Le livre Practical Symfony, sorti à la fin de 2008, est un excellent moyen pour un débutant d’apprendre symfony, de comprendre comment il fonctionne, et aussi de voir, par l’action, les meilleures pratiques de développement web.

Fonctionnalités :

Symfony propose entre autres :

  • Une séparation du code en trois couches, selon le modèle MVC, pour une plus grande maintenabilité et évolutivité
  • Un templating simple, basé sur PHP et des jeux de “helpers”, ou fonctions additionnelles pour les gabarits…
  • Des performances optimisées et un système de cache pour garantir des temps de réponse optimums
  • Une gestion des url parlantes, qui permet de formater l’url d’une page indépendamment de sa position dans l’arborescence fonctionnelle
  • Un système de configuration en cascade qui utilise de façon extensive le langage YAML
  • Un générateur de back-office et un “démarreur de module” (scaffolding)
  • Un support de l’internationalisation - symfony est nativement multi-langue,
  • Une couche de mapping objet-relationnel (ORM) et une couche d’abstraction de données
  • Le support de l’AJAX
  • Une architecture extensible, permettant la création et l’utilisation de plugins

Pour une présentation compète de symfony, rendez-vous à l’adresse :
http://www.do-as-i-say.com/notes/2009/08/framework-symfony-explique-a-ma-maman-1/

Pour voir une présentation vidéo de symfony  réalisée par les membres de développez.com :
http://php.developpez.tv/presentation-symfony-2007/

Le design pattern MVC et l’objet

symfony est entièrement basé sur le design pattern MVC (Modèle-Vue- Contrôleur). Utilisé dans d’autres technologies (notamment Java), il n’a été largement diffusé dans le monde PHP qu’avec des frameworks tels que symfony. Le MVC est un pattern architectural qui sépare les données (c’est-à-dire le modèle), l’interface homme-machine (la vue) et la logique de contrôle (le contrôleur).

Le fonctionnement du MVC
Ce modèle de conception impose donc une séparation en 3 couches : - Le modèle : Il représente les données de l’application. Il définit aussi l’interaction avec la base de données et le traitement de ces données. - La vue : Elle représente l’interface utilisateur, ce avec quoi il interagit. Elle n’effectue aucun traitement, elle se contente simplement d’afficher les données que lui fournit le modèle. Il peut tout à fait y avoir plusieurs vues qui présentent les données d’un même modèle. - Le contrôleur : Il gère l’interface entre le modèle et le client. Il va interpréter la requête de ce dernier pour lui envoyer la vue correspondante. Il effectue la synchronisation entre le modèle et les vues. symfony implémente donc trois couches répondant à ce pattern. Le schéma ci-dessous illustre le mécanisme du MVC dans un projet symfony lorsque l’utilisateur navigue sur le site.

Le MVC dans symfony
Pour une courte introduction à MVC, je vous conseille la lecture de la première partie du tutoriel de Baptiste Wicht (pour une introduction rapide), et la lecture du cours de Serge Tahé pour aller plus loin.

 

Installer symfony

Pour installer symfony, la méthode la plus fiable est de passer par SVN.
Il faut donc installer un client svn en local avec un accès en CLI. (visual svn par exemple : http://www.visualsvn.com/)
Ensuite Installer un serveur web en local.
Soit en installant apache, mysql et php séparément, soit à l’aide d’un wamp.
/!\ attention une version de php inférieure à la 5.3 est obligatoire.
Ensuite, pour installer symfony proprement dit, suivre le tutoriel a l’adresse : http://www.sadai.net/installer-symfony-avec-svn

 

Amorcer le projet

Symfony demande de porter une attention particulière à l’avant projet.
Il faut soigneusement choisir  les plugins nécessaires au développement, et les tester pour s’assurer qu’ils fonctionnent !

Il faut également choisir son ORM (http://fr.wikipedia.org/wiki/Object-relational_mapping) parmi Propel et Doctrine que propose symfony.
Il est aujourd’hui conseillé d’utiliser Doctrine, mais sur les versions de symfony inférieures à la 1.3, c’est Propel qui était utilisé. L’utilisation de doctrine peut donc poser des problèmes de compatibilité avec les plugins.
Plusieurs plugins (sympal, w3StudioCms, etc…) risquent de se révéler inutilisables.

 

Modéliser le projet

Une fois les plugins choisis et installés, nous pouvons passer à la modélisation du projet.
Rendez vous dans le répertoire « trunk Â» de votre dépôt SVN avec la ligne de commande, créez un nouveau dossier avec le nom que vous souhaitez, puis entrez dans celui-ci.
Ces actions devraient donner a peut près ceci :

cd
\wamp\www\trunk\
mkdir monProjet
cd monProjet
 
Ensuite symfony va vous générer la structure de base qui vous permettra de débuter votre projet :
symfony generate:project monProjet

La base de données

Symfony permet d’utiliser un modèle et des données test, qu’il  insuffle directement dans la base.
A partir de ce modèle, il crée une arborescence complexe de classes pour les relations avec la BDD et pour l’utilisation du formulaire.
Mais à chaque mise à jour de ces éléments (nous parlerons plus tard de build-all et de data-load) toutes les données de la base sont effacées.

Il est donc important de bien penser sa base de données avant de commencer le projet pour éviter les manœuvres complexes de sauvegarde et de réinjection des données.
La création de la base de données ne se fait pas comme dans un autre projet.
Afin d’assurer la fiabilité et l’évolution du projet, il est conseillé de créer la base dans le fichier schéma.yml qui se trouve dans le dossier Â« config Â» à la racine de votre projet.
Pour créer le ficher, suivez les conseils que prodigue cette page : http://www.symfony-project.org/jobeet/1_2/Doctrine/en/03 dans la partie « The relational Model Â»

Il reste encore à configurer les accès de symfony à votre base, cela ce fait dans le fichier : config/databases.yml
Avec propel, vous pouvez également utiliser la commande :

symfony configure:database --name=doctrine --class=sfDoctrineDatabase “mysql:host=localhost;dbname=maBase" user MotDePasse

Vous pouvez désormais créer les tables de votre base avec la commande :

symfony propel:build-all Ou symfony  doctrine:build-all

Voila, le projet est créé, les tables sont créées et ils communiquent entre eux.


La structure du projet

La structure d’un projet Symfony est composé de 10 dossiers :

apps/
cache/
config/
data/
doc/
lib/
log/
plugins/
test/
web/

Ces dossiers sont les plus importants car ils constituent le cÅ“ur de notre projet Symfony :
  • le dossier apps contiendra nos futurs applications qui sont en faite nos différentes parties de site (généralement les applications frontoffice et backoffice).
  • le dossier cache contient les pages mises en cache par Symfony
  • le dossier config contient les fichiers de configuration du projet dont notamment ceux de la base de données
    pour tout savoir sur la configuration :
    http://www.symfony-project.org/reference/1_3/fr/03-Configuration-Files-Principles
  • le dossier data vous permet de déposer les documents liés au projet (analyse UML, schéma de la base de données)
  • le dossier doc contiendra la documentation lié au projet
  • le dossier lib contient deux sous dossiers importants que sont form et model qui contiennent respectivement tous les formulaires du site (car avec Symfony, les formulaires ne sont pas du simple code html mais des objets que Symfony créera pour vous simplifier la vie) et le second dossier model stocke tout ce qui concerne les accès aux champs de votre base de données.
  • le dossier log contient les informations logués par Symfony sur vos différentes applications
  • le dossier plugins vous permet de déposer les différents plugins crées par la communauté de Symfony
  • le dossier test contient les tests unitaires de Symfony
  • le dossier web contient aussi plusieurs dossiers qui contiendront vos feuilles de styles CSS, les images, les scripts javascripts
    C’est le seul dossier accessible de votre site.
    C’est donc avec cette adresse que vous pourrez voir votre site. (ex : http://localhost/ trunk/monProjet/web/index.php)


Les fichiers YAMEL

Symfony utilise des fichiers YAML (.yml) pour les paramétrages. Ils remplissent le même rôle que des fichiers XML mais sont plus facile a lire et a créer.
Pour tout savoir sur les fichiers YAML :
http://www.symfony-project.org/reference/1_3/fr/02-YAML

 

Les applications

Chacune de vos applications représente une partie de votre site.
Pour un site vitrine, une seule application peut suffire, pour un site administrable, une application frontoffice et une application admin vont être nécessaires etc…

Une application à une arborescence imposée.
Pour nous faciliter la tache, symfony nous les crée avec une commande :

Symfony generate:app frontend

Ou en version securisé :

symfony generate:app --escaping-strategy=on --csrf-secret=MoCode47SecretMP frontend

Cette commande affichera un listing de tous les dossiers et fichiers créés grâce à cette commande.
Ensuite explorez le dossier apps de votre projet Symfony pour voir les changements :

frontend/
config/
i18n/
lib/
modules/
templates/

Un dossier racine dans apps nommé frontend est maintenant disponible. Les sous-dossiers ressemblent étrangement à ceux de la racine de notre projet. En effet, certains sont semblables.
  • Le dossier config regroupe les différents fichiers de configuration de notre APPLICATION frontend. En effet, il y a des fichiers de configuration au niveau du projet puis plus spécifiquement au niveau de l’application en elle-même permettant d’overrider ceux définis au niveau du projet.
  • Le dossier i8n permet de déposer les fichiers d’internationalisation de l’application.
  • Le dossier lib permet de modifier le comportement de l’application, ou d’ajouter des classes pour votre application
  • Le dossier modules contiendra les différents modules de notre application. Un module est une partie de notre application, par exemple dans notre frontoffice, on aura les modules : accueil, membres, actualités…

    C’est en réalité dans ces modules que tout va se passer.
    Le dossier templates contiendra la structure des pages des modules. C’est ici qu’il faudra designer et structurer les modules de l’application.
    Symfony gère le templating à l’aide d’un layout.php, qui appel des « partials Â» ou des « components Â».
    Vous pouvez maintenant essayer votre toute premiére page Symfony en vous rendant à cette adresse : http://localhost/trunk/web/frontend_dev.php/
    On peut voir que la fin de cette adresse est : frontend_dev.php
    Et pourquoi ” _dev ” ? tout simplement pour que lors de votre développement vous ayez accès à une barre de débug Symfony montrant notamment vos requêtes SQL. L’adresse en production de votre page finira bien par frontend.php.

 

la configuration de l’application                 

La configuration de l’application principale est stockée dans des fichiers situés dans le répertoire myproject/apps/myapp/config/:

  • app.yml : Ce fichier contient la configuration spécifique à l’application ; c’est-à-dire les variables globales définissant la logique applicative spécifique à une application, n’ayant pas besoin d’être stockées dans une base de données. Taux des taxes, frais de ports, et e-mail sont souvent stockés dans ce fichier. Il est vide par défaut.
  • cache.yml : permet de paramétrer les options de cache de l’application
  • config.php : Ce fichier amorce l’application, ce qui veut dire qu’il réalise les initialisations permettant à l’application de démarrer. C’est ici que vous pouvez personnaliser votre structure de fichiers ou ajouter des constantes spécifiques à l’application Il démarre en incluant le fichier config.php du projet.
  • factories.yml : Symfony définit ses propres classes pour gérer la vue, les requêtes, les réponses, les sessions, … . Si vous souhaitez utiliser vos propres classes, c’est ici que vous pouvez les définir.
  • filters.yml : Les filtres sont des portions de code exécutés à chaque requête. C’est ici que vous définissez quels filtres sont traités, et ils peuvent êtres modifiés pour chaque module.
  • logging.yml : Ce fichier définit le niveau de détails devant être enregistré dans les logs, pour vous aider à gérer et à debugger votre application.
  • routing.yml : Les règles de routage, permettant de transformer les urls illisibles et « unbookmarkable Â» en de belles urls, sont stockées dans ce fichier. Pour de nouvelles applications, quelques règles par défaut existent.
  • settings.yml : Les paramètres principaux d’une application symfony sont stockés dans ce fichier. C’est ici que vous définissez si votre application est à vocation internationale, son langage par défaut, le timeout d’une requête, et si le cache est actif. En changeant une seule ligne dans ce fichier, vous pouvez interrompre l’application vous permettant la maintenance ou la mise à jour d’un de ses composants.
  • view.yml : La structure de la vue par défaut (nom du layout, titre, et tags meta; feuilles de styles par défaut et les fichiers JavaScript à inclure ; content-type par défaut, …) est définit dans ce fichier.
Configuration supplémentaire pour l’application :
Un seconde ensemble de fichiers de configuration se trouve dans le répertoire d’installation de symfony (dans $sf_symfony_ data_dir/config/) et n’apparaît pas dans le répertoire de configuration de votre application. Les paramètres définis ici sont rarement modifiés, ou global à tous les projets. Cependant, si vous avez besoin de les modifier, créer un fichier vide portant le même nom dans le répertoire myproject/apps/myapp/config/, et modifiez les paramètres que vous souhaitez changer. Les paramètres définis dans une application sont toujours prioritaires sur ceux définis dans le framework. Les fichiers de configurations sivants sont ceux du répertoire d’installation de symfony/config :
  • autoload.yml : Ce fichier contient les paramètres de la fonctionnalité d’auto chargement.
  • constants.php : Ce fichier contient la structure de fichier par défaut de l’application. Pour modifier les paramètres de ce fichier, utilisez le fichier config.php de l’application.
  • core_compile.yml et bootstrap_compile.yml : C’est la liste des classes à inclure lors du démarrage de l’application (dans bootstrap_compile.yml) et pour traiter une requête (dans core_compile.yml). Ces classes sont en fait concaténées dans un fichier PHP optimisé sans commentaires, ce qui va accélérer l’exécution en minimisant les opérations d’accès au fichier (un seul fichier est chargé au lieu d’une quarantaine à chaque requête)..
  • config_handlers.yml : C’est ici que vous pouvez ajouter ou modifier les gestionnaires utilisés pour traiter chaque fichier de configuration.
  • php.yml : Ce fichier vérifie sur les variables du fichier php.ini sont correctement définies et vous permet de les modifier, si nécessaire. Regardez le chapitre 19 pour plus de détails.

Pour plus de détails sur la configuration de symfony :
http://trac.symfony-project.org/wiki/Documentation/fr_FR/book/1.0/trunk/05-Configuring-Symfony


Templates 

Pour tout savoir sur les layout, templates, et partials, lisez l’excellent tutoriel suivant : http://www.lafermeduweb.net/tutorial/les-templates-layout-et-helpers-dans-symfony-p36.html

           J’ajouterai juste que l’utilisation de partial est limitée, pour pouvoir utiliser des codes complexes dans un template partiel, il faut utiliser un component.
Le component fonctionne exactement comme un template classique (indexSuccess.php), et est précéder d’un underscore, comme un partial (ex : _monComponent.php)
Pour l’appeler dans un layout (mais aussi dans un partial, dans un template, ou dans un component) il faut utiliser la syntaxe :

include_component('module', 'component'); voir également la fiche résumé en anglais en PJ : symfony_partials.pdf

Pour que l’architecture de votre application reste logique et compréhensible sans avoir à trop refactoriser. Il est possible de créer un module dans lequel vous pourrez stocker tous les partials de l’application en général


Modules 

Dans les modules, on gère les chaque partie du site.
Dans le cadre d’une application d’administration on va donc avoir un module message, un module page, un module user etc…

Un module a lui aussi une arborescence obligatoire.

Et donc, il y a une ligne de commande pour le créer :

Symfony generate:module nomDeLApplication nomDuModule

Dans le module on trouve au  minimum les répertoires :

  • /actions qui contient le fichier actions.class.php qui lui même contient les méthodes à exécuter en fonction de l’Url appelée. C’est donc la partie “Contrôleur” du modèle MVC.
  • /templates qui contient la liste des templates HTML associés à chaque action publique du fichier actions.class.php. C’est donc la partie “Vue” du modèle MVC.

On peut également trouver des répertoires optionnels comme :

  • /i18n qui contient les dictionnaires de traduction propres au module dans le cas d’une application multilingue,
  • /config qui contient des fichiers de configuration propre au module,
  • /lib qui contient des classes propres au bon fonctionnement du module. Dans ces classes, tu peux avoir des classes de modèle, donc appartenant à la couche “Modèle” de MVC.

Chaque application est visualisable a l’adresse :  /web/nomdelapplication.php pour la production et /web/nomdelapplication_dev.php pour le développement.

Si la modélisation de votre projet à été bien réalisée, vous devriez à ce stade pouvoir créer toute l’arborescence d’applications et de modules de ce projet.
Ne créer pour l’instant que les applications. Nous utiliserons une fonctionnalité de symfony pour créer les plus importantes, et nous compléterons ensuite avec les applications plus spécifiques.

 

Le routing 

Il est temps de penser a la manière de router votre application.
Le routing par défaut d’un projet symfony est :

http://www.monSite.tdl/nomApplication.php/nomModule/nomAction/paramettres

Ça n’est pas très « user friendly Â» et c’est encore moins bon pour les moteurs de recherches.

Il faut donc modifier le fichier routing.yml pour prévoir le routing que vous souhaitez.

Par exemple on peut ajouter une règle de routage au fichier comme ceci : 

contenu:
   url:   /article/:nom
   param: {module:contenu, action: index }
  • « contenu Â» est le nom de la règle de routing
  • « url Â» est la manière dont l’url doit être envoyée pour que symfony la comprenne
    ici une url du type http://www.monsite.com/article/mon-article utilisera cette règle.
  • « Param  Â» : une liste de paramètre qui se déclenche quand l’url entre dans la règle de rooting.
    L’url ci-dessous sera donc renvoyée vers le module « contenu Â» et l’action « index Â», avec une variable Â« nom Â»qui contiendra « mon-article Â».
Il est important de définir le maximum de règles qui vont vous être nécessaire dès maintenant pour éviter d’avoir à modifier tous les liens de votre site une fois qu’il est terminé.

Lorsque vous créerez des liens sur cette application il faudra pour fonctionner qu’elle soit sous la forme « /article/< ?php echo $nom; ?>

nb : Un des points fort de symfony est l’utilisation de helpers. Les liens ne se font donc JAMAIS en directe dans le code
Pas de

<a href=’article/mon-article’ />

mais

<?php echo (link_to($name=$ nomPourLeLien, $internal_uri = "article/".$titreArticle)  ) ; ?>


> Voir chapitre Helpers.

Nb2 : pour retrouver un titre par son nom, vous devrez d’abord le normaliser en utilisant une fonction type « slug Â» que vous placerez dans une classe du dossier lib de votre projet.
Cette fonction doit supprimer les espace, les accents etc… pour que le nom soit à coup sur juste pour une URL.
Dans l’exemple ci-dessus, le lien ressemblera plus à  :

link_to($name$nom, $internal_uri = "article/".slug($titre));


Les cruds

L’arborescence est en place, le layout est créé, le modèle de données également, on peut désormais entrer dans le vif du sujet.
La préparation semble longue mais en réalité beaucoup de choses ont été réalisées par symfony.
Il a déjà créé les modèles d’accès à la Base de Données, et  les formulaires (quand vous avez executé la commande « build-all Â»).
Il va juste falloir en créer l’affichage.

Pour mémoire, un CRUD est l’abreviation de Create, read, update and delete, les quatres principales actions réalisées sur les BDD.

Nous allons donc créer des CRUDs en ajoutant un détail, un parramettre permetant de créer une vue d’une ligne de la base de donnée.
Retournez dans votre ligne de commande et entrez :

symfony propel:generate-crud nomApplication nomModule NomTableBDD –with-show

Attention le nom de la table doit commencer par une majuscule.

Symfony vous a créé un module qui vous permet de lister les entrées de la BDD, de les afficher, de les supprimer ou d’en créer de nouvelles.

En d’autres termes vous venez de créer une interface d’administration pour votre table.
Pour n’avoir que l’affichage, créez un crud et enlever dans le code du template showSuccess.php les informations qui vous gènes et les liens.

Supprimez dans le ficher action (monModule/action/action.class.php) les actions devenues inutiles.

Enfin supprimez les templates devenus inutiles. (Tous sauf showSuccess.php)
Il vous suffit d’ajouter un menu (et de gérer le routing dans le fichier action.class.php) et vous avez créé votre site.

 

Modifier les formulaires

Les crud sont efficace mais les formulaires qu’ils génèrent sont rarement parfaitement adaptés à nos besoins.
Ors si vous vous contentez de modifier les formulaires dans la vue (le template _form) il vous renverra une erreur.

Pour modifier les formulaires il faut sortir de l’application  et se rendre dans le dossier /lib/form de votre projet.

Vous trouverez une class par table de votre base de données.
C’est en modifiant l’une de ces classes que vous modifierez le formulaire correspondant.

Par défaut elles sont vides. Les formulaires générés automatiquement se trouvent dans le dossier base. Il ne faut pas les modifier !
Ouvrez donc l’une des classes, et suivez le tutoriel de la page suivante pour les modifier comme vous le souhaitez.
http://www.symfony-project.org/forms/1_1/fr/01-Form-Creation

 

Les autres actions et leurs vues

Mais toutes les actions ne rentrent pas dans le cadre du Crud

Pour les modules qui ne rentrent pas du tous dans le cadre d’un crud, nous allons utiliser la création d’un module classique.
Rappel :

Symfony generate:module nomDeLApplication nomDuModule

Si vous souhaitez ajouter des actions dans un module existant, ajoutez une action dans l’action.class.php du module.
le nom d’une action doit toujours être formaté tel que :

public function executeNomAction(){}

qui correspond à un template dans le même module qui se nommera « nomActionSuccess.php Â»

/!\ Les actions ne font que mettre en relation les modèles et la vue, ou gérer les retours de l’utilisateur.
Une action bien codée ne doit pas faire plus de 10 lignes.


Les modèles

C’est dans la partie modèle du dossier Lib/model/ de votre projet que doivent être gérés toutes les requêtes.
Cela permet de mutualiser les fonctions et de faciliter la maintenance.
Le dossier est structuré comme le dossier Form.
Les classes de base sont dans om. Se sont toutes les classes permettant de faire des requêtes, de gérer les clefs externes, etc…
Il ne faut donc surtout pas les modifier  !

Dans les classes suivantes, vous donc ferez beaucoup de requêtes.
Mais propel ou doctrines font beaucoup de travaille à votre place.
Je vous invite donc à lire le chapitre suivant.

 

Les requêtes

En générant les modèles, symfony crée des classes permettant de manipuler chaque table, en facilitant l’ajout de critère de recherche, ou d’ordonnancement entre autre.
Si vous utilisez Doctrine, allez voir cette partie du tutoriel officiel de symfony :
http://www.symfony-project.org/jobeet/1_2/Doctrine/en/06


Si vous utilisez Propel, allez voir cette partie du tutoriel officiel de symfony :
http://www.symfony-project.org/jobeet/1_2/Propel/en/06

Pour un condensé des possibilités du criteria de propel : http://andreiabohner.files.wordpress.com/2008/01/sfmodelcriteriacriterionrsrefcard_enus.pdf

 

Les Helpers 

Les helpers sont des méthodes php qui génèrent du code dans vos templates.
Ils permettent de générer du code propre, respectueux des standards et tout ceci simplement. Les helpers sont présents dans de nombreux domaines : Javascript, AJAX, Flash, formatage de données, régionalisation, et les formulaires.
L’utilisation des helpers fait gagner du temps et évite de nombreux problèmes.
Les helpers sont nombreux et divers, pas d’autre choix que d’aller faire un tour dans l’api pour voir leur étendue :
http://www.symfony-project.org/api/1_2/helper

 

Le dossier WEB

Comme nous l’avons évoqué précédemment, c’est le seul dossier accessible depuis votre navigateur.
On y trouve les éléments qui doivent être interprétés directement par le navigateur.
En créant le projet, l’architecture du dossier à été générée automatiquement.
En créant les applications, vous avez généré également le fichier php qui permet d’y accéder.

Dans le dossier Web on retrouve donc :

  • Un ficher « index.php Â»
  • Un fichier « monApplication.php Â» qui est l’adresse de production qui permet d’accéder à l’application. (il faudra donc en paramétrer une par défaut)
  • Un fichier « monApplication_dev.php Â» qui est l’adresse de développement qui permet d’accéder à l’application en environnement développement. Elle donne accès à des messages d’erreurs symfony et à une toolbar donnant des informations utiles au développement de votre page.
  •  Un fichier robots.txt à paramétrer comme vous le souhaiter pour les spiders des moteurs de recherche
  • Un fichier Â« .htaccess Â» qui défini certaines règle d’accès au dossier
  • Un dossier « CSS Â», dans lequel vous pourrez stocker toutes vos feuilles de styles.
    Pour les appeler dans une application (ou meme dans un module), vous devez ajouter une ligne  dans le fichier view.yml du repertoire config de votre application ou de votre module. (dans le cas d’un module il faudra créer le dossier et le fichier à la main)
        stylesheets: [page.css, hp.css]
  • Un dossier images qui comme son nom l’indique vous servira à stocker les images du site.
  • Un dossier « js Â»  pour vosfichiers javascripts.
    Comme pour les css, il faut les ajouter dans le fichier view.yml
    javascripts:    [jquery.js, jquery.droppy.js, jquery.example.js, jquery.tools.min.js, defaut.js]
  • Un dossier uploads (qui n’existera probablement pas à la création de votre projet) ou sont regroupés les fichiers téléchargés par l’utilisateur dans un champs File du site.

  

Modélisation d’une action gérée par symfony : 




 Le dossier Plugin

C’est dans ce dossier que s’installe les plugins du site.
Chaque plugin est en réalité un mini projet avec son arborescence propre.
Pour trouver un plugin :
http://www.symfony-project.org/plugins/

Pour installer un plugin suivez scrupuleusement les indications qui se trouvent dans la partie « readme Â» de chaque plugin.
Pour activer un plugin dans votre application, vous devez l’ajouter dans le fichier settings.yml

enabled_modules: [default, sfCryptoCaptcha]

 

 Le cache

Symfony intègre un système de cache assez efficace, qui stocke toutes les informations réutilisable du site.

Vous devrez donc vider ce cache à chaque modification importante sur votre projet (un fichier de configuration, création d’une nouvelle classe, installation d’un plugin…)
Vider le cache se fait en ligne de commande :

symfony cc

Voici un billet intéressant sur le clear:cache
http://clear-cache.fr/?post/2009/07/29/Clear-Cache

  

Les tests

Symfony offre la possibilité de créer des tests unitaires pour votre projet.
Pour en savoir plus sur les tests :
http://www.symfony-project.org/cookbook/1_2/fr/model_unit_testing

Liens utiles :